< sipa> MarcoFalke: f*cking heisenbug
< sipa> if i even just add a printf of the input to the hash functions in the test, it goes away
< fanquake> >.>
< luke-jr> sipa: what if you nexti through it?
< sipa> MarcoFalke: every time line 551 in crypto_tests.cpp executes, it overwrites the first 64 bytes of the "in" array (regardless of the value of j, always the first 64 bytes...)
< sipa> this makes no sense whatsoever
< sipa> perhaps the intermediary sha256 result (created in CHash256::Finalize) somehow is places on the stack there
< sipa> oh no, just the first 32 bytes
< luke-jr> * [new tag] v0.18.0.knots20190502 -> v0.18.0.knots20190502 on https://github.com/bitcoinknots/bitcoin/
< luke-jr> wumpus: ^
< luke-jr> why isn't https://bitcoincore.org/en/2019/05/02/release-0.18.0/ linked from the main webpage?
< luke-jr> roconnor: if not, open an issue
< roconnor> Heh I'm not sure I could tell if it were out of date or not.
< luke-jr> hmm, I got a build mismatch on bitcoin-0.18.0-osx-unsigned.tar.gz
< fanquake> dongcarl: Had a quick look at guix 1.0.0, my current build setup (swapping 0.16.0 with 1.0.0) breaks with something locale related. Have you had a chance to look at 1.0.0?
< luke-jr> all my Linux gitian outputs mismatch
< jonasschnelli> Would it make sense to significant reduce MAX_BLOCKFILE_SIZE in regtest in order to test pruning?
< jonasschnelli> ^ MarcoFalke
< jonasschnelli> I know I commended just a while ago against changing internals for faster testing... though pruning is really hard to test in regtest
< jonasschnelli> Also, I expect that pruning will get more important over time
< wumpus> luke-jr: having some problem with "No space left on device" during gitian build, will look into it later
< fanquake> wumpus: potentially related to https://github.com/devrandom/gitian-builder/pull/212
< harding> luke-jr: what do you mean "why isn't https://bitcoincore.org/en/2019/05/02/release-0.18.0/ linked from the main webpage?" On https://bitcoincore.org/, the first item in "Recent posts" points there for me.
< wumpus> fanquake: think so too; though I had the issue once with bitcoin core too, then increased the image size, but apparently not enough
< luke-jr> harding: it only shows 0.17.1 and older on https://bitcoincore.org/ for me
< luke-jr> Shift-reload fixes.. cache header issue?
< bitcoin-git> [bitcoin] Bushstar opened pull request #15945: net: Log unknown CInv in PushInventory (master...cinv-unknown) https://github.com/bitcoin/bitcoin/pull/15945
< luke-jr> as for the gitian mismatch, I wiped my cache and am rebuilding from scratch
< luke-jr> hopefully that will match and I can compare
< dongcarl> fanquake: Yeah 1.0.0 seems to work but I've got a lot of unpushed changes right now. I will push something up next week though. I made r(un)paths go away without patchelf hacks and cross-compiling works for i686-linux-gnu, arm-linux-gnueabihf, and aarch64-linux-gnu
< bitcoin-git> [bitcoin] jonasschnelli opened pull request #15946: Allow maintaining the blockfilterindex when using prune (master...2019/05/prune_blockfilter) https://github.com/bitcoin/bitcoin/pull/15946
< luke-jr> hmm, rebuild from scratch ended up with the same mismatching hash for macOS tar.gz :/
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/24dfcf3a56f9...94daebf327e3
< bitcoin-git> bitcoin/master fa1c359 MarcoFalke: rpc: Use IsValidNumArgs in getblock
< bitcoin-git> bitcoin/master fab00a5 MarcoFalke: rpc: Serialize in getblock without cs_main
< bitcoin-git> bitcoin/master faea564 MarcoFalke: rpc: Add lock annotations to block{,header}ToJSON
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15932: rpc: Serialize in getblock without cs_main (master...1905-rpcBlockNoLock) https://github.com/bitcoin/bitcoin/pull/15932
< bitcoin-git> [bitcoin] domob1812 opened pull request #15947: Install bitcoin-wallet manpage (master...install-wallet-man) https://github.com/bitcoin/bitcoin/pull/15947
< MarcoFalke> [05:11] <jonasschnelli> Would it make sense to significant reduce MAX_BLOCKFILE_SIZE in regtest in order to test pruning?
< MarcoFalke> Yeah, there are some tradoffs with a minimal patch to bitcoind to ease testing. You can easily argue either way very strongly
< MarcoFalke> Will probably raise this topic in a meeting, but rn I don't feel like shedding this further
< roconnor> luke-jr: is "rapidcheck" something that should go into the dependencies.md, or does it not count?
< MarcoFalke> It is only for tests
< MarcoFalke> and highly experimental
< roconnor> (as in I didn't know that rapidcheck was a thing that I should perhaps be using)
< roconnor> oh highly experimental.
< MarcoFalke> don't let me hold you back from having fun with it
< roconnor> FWIW, Python is also used only for tests and it is listed. I think if rapidcheck weren't highly experimental, it would go into the list.
< jonasschnelli> Funny... the ASan/LSan x86_64 bit linux travis job just needs to get re-kicked until its running through... reminds me of hitting a vendor machine
< sipa> jonasschnelli: i once had a CRT screen whose red color would sometimes disappear; if you hit it hard enough, it would come back
< MarcoFalke> someone could disable the pruning test on asan
< MarcoFalke> or reduce the block size, as per jonas
< jonasschnelli> sipa: heh. Yeah. I had similar issues with CRT screens...
< sipa> it was 20 years ago, though
< MarcoFalke> I had the issue with tft screens with specific pixels. And if you presses the pixel hard enough it would also back
< MarcoFalke> s/presses/pressed s/back/come back
< bitcoin-git> [bitcoin] jamesob opened pull request #15948: refactor: rename chainActive (master...2019-05-au-chainactive) https://github.com/bitcoin/bitcoin/pull/15948
< jamesob> fanquake: whenever you get a sec, can you add the above to https://github.com/bitcoin/bitcoin/projects/11?
< jnewbery> jamesob: done
< jamesob> jnewbery: tyty
< MarcoFalke> Looks like people are still using win32: https://github.com/bitcoin/bitcoin/pull/15939#discussion_r280891756
< gmaxwell> Give just him an binary and continue to collect reports? :P
< MarcoFalke> I think a lot of people are too shy to complain
< MarcoFalke> I'd say revisit in 3 or 5 years
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15949: test_runner: Move pruning back to extended (master...1905-testPruneExt) https://github.com/bitcoin/bitcoin/pull/15949
< midnightmagic> sipa: hey your hashrate graphs aren't updating or something
< * midnightmagic> prods
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/94daebf327e3...f19a3b2ded4b
< bitcoin-git> bitcoin/master fa08c5c MarcoFalke: test_runner: Move pruning back to extended
< bitcoin-git> bitcoin/master f19a3b2 MarcoFalke: Merge #15949: test_runner: Move pruning back to extended
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15949: test_runner: Move pruning back to extended (master...1905-testPruneExt) https://github.com/bitcoin/bitcoin/pull/15949
< MarcoFalke> #proposedmeetingtopic windows 32 bit
< luke-jr> MarcoFalke: maybe rapidcheck shouldn't enable by default?
< bitcoin-git> [bitcoin] sipa opened pull request #15950: Do not construct out-of-bound pointers in SHA2 code (master...201905_shapointerissue) https://github.com/bitcoin/bitcoin/pull/15950
< MarcoFalke> luke-jr: It isn't
< MarcoFalke> wait, maybe it is
< MarcoFalke> I thought you had to pass RAPIDCHECK=1 in depends
< luke-jr> MarcoFalke: most people hopefully don't use depends at all :P
< luke-jr> afaik it enables by default if rapidcheck is installed
< MarcoFalke> ouch, so we shipped 0.18.0 test_bitcoin with rapidcheck?
< * gmaxwell> thumbsdown functionality that depends on autodetection.
< gmaxwell> on the plus side approximately no users run the tests. :P
< gmaxwell> (?)
< luke-jr> MarcoFalke: doubt it - that would only be the case if the gitian images had rapidcheck?
< MarcoFalke> gitian builds from depends
< luke-jr> although I haven't figured out why my gitian builds didn't match yet
< luke-jr> the binaries seem completely different :\ even bitcoin-cli
< luke-jr> MarcoFalke: but do depends build rapidcheck by default?
< gwillen> sipa: is the 'end' pointer really out of bound?
< gwillen> it should be "one past the end" of an object (at worst), which should be permitted, yes?
< sipa> oh!
< sipa> yes, it is
< sipa> ah, now i remember: the "end >= data + 128" constructs a possibly out of bounds pointer
< MarcoFalke> luke-jr: no, so I guess we are good
< gwillen> ahhhhh
< sipa> gwillen: though that could be fixed by using "end - data >= 128" instead of this larger patch
< luke-jr> MarcoFalke: well, it might still make sense not to enable it by default at all
< MarcoFalke> yeah
< luke-jr> aha, discovered I have apt-cacher-ng in OfflineMode - bet that's why my builds don't match
< luke-jr> does anyone want to troubleshoot this, or should I just let it update? (wumpus, cfields)
< MarcoFalke> luke-jr: that is expected, right
< MarcoFalke> Hopefully 0.19.0 will be releases on guix, with the toolchain and all dependecies in our control
< luke-jr> MarcoFalke: it's expected? :|
< luke-jr> I would have expected updates to be just bugfixes, not stuff radically changing output
< MarcoFalke> Yeah, if you built with an outdated version of gcc, it will produce a different result
< MarcoFalke> Might just be the compiler version str or something
< luke-jr> maybe. hopefully without malware injecting :x
< * luke-jr> makes a backup of /var/cache/apt-cacher-ng in case anyone is interested