< 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
< 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
< 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 :/
< 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
< 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