< dhruvm> If I run FUZZ=process_message src/test/fuzz/fuzz qa-assets/fuzz_seed_corpus/process_message and it creates a new file in qa-assets/fuzz_seed_corpus/process_message/..., does that mean this run uncovered an input that can increase converage?
< sipa> dhruvm: or a shorter input than an existing one with the same coverage
< dhruvm> so they are always worth contributing back to the corpus?
< dhruvm> also, reg the line that starts with "INITED": does that mean all the seeds in the corpus were tried, and now, the fuzzer will mutate them to try and increase coverage?
< sipa> yes
< dhruvm> perfect, thanks.
< phantomcircuit> sipa, are all the fuzzing targets in the same binary again?
< sipa> phantomcircuit: yes
< sipa> env variable to select which fuzz target you want
< sipa> FUZZ=txrequest ./src/test/fuzz/fuzz
< phantomcircuit> sipa, iirc that significantly reduces the effectiveness of the fuzzing, wasn't it broken out before?
< phantomcircuit> (i know the original was not, but i thought that was fixed)
< sipa> phantomcircuit: we benchmarked it, and it doesn't really affect it
< sipa> what does affect fuzzing effectively is taking the fuzz target from the _input_
< sipa> but we don't do that now; it's taking the target from an env var
< phantomcircuit> sipa, oh interesting
< phantomcircuit> i wouldn't have expected that
< sipa> the problem is that if the fuzz target is taken from the input, it'll try to cross-pollinate inputs across targets
< phantomcircuit> the docs say pretty clearly that reducing the number of branches will make the actual fuzzing not necessarily faster, but better since there will be fewer collisions in the uh ... branch marking things
< phantomcircuit> but it's probably not that significant with the targets we're fuzzing
< sipa> yeah, and many fuzz targets link in large amounts of the codebase anyway
< sipa> which means there isn't too much difference between the amount of reachable branches in the code
< phantomcircuit> sipa, makes sense
< sipa> (and without -flto and -ffunction-sections it probably doesn't matter at all, as tons of unreachable branches will stay in the binary)
< bitcoin-git> [bitcoin] fanquake closed pull request #20719: (master) (master...(master)) https://github.com/bitcoin/bitcoin/pull/20719
< achow101> code signing tool might be ready for rc4 :)
< achow101> s/for/by
< phantomcircuit> sipa, er am i missing something, im following the docs in docs/fuzzing.md to build and this is definitely not working
< phantomcircuit> /usr/bin/ld: error: test/fuzz/fuzz-crypto_chacha20_poly1305_aead.o: <corrupt x86 feature size: 0x8>
< phantomcircuit> infinite more errors just like that
< sipa> what OS?
< phantomcircuit> debian 10
< phantomcircuit> went most universal thing i could without using ubuntu
< sipa> never seen that error
< sipa> x86_64 i presume?
< phantomcircuit> sipa, yes
< phantomcircuit> sipa, yeah i haven't either
< sipa> and you did a make clean or so?
< sipa> or started from a cpean source tree
< phantomcircuit> it's a brand new source tree
< sipa> which gcc or clang?
< phantomcircuit> sipa, first clang which gave that error and now gcc which also gives the same error (error is from ld)
< sipa> which version is it?
< phantomcircuit> sipa, of what
< phantomcircuit> f1dbf92ff0475a01d20170ea422c1d086acbbc57
< phantomcircuit> clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final)
< phantomcircuit> gcc (Debian 8.3.0-6) 8.3.0
< phantomcircuit> GNU ld (GNU Binutils for Debian) 2.31.1
< sipa> should be recent enough
< phantomcircuit> sipa, im going to blow away and start over maybe something is messed up
< phantomcircuit> sipa, hmm i just noticed
< phantomcircuit> Makefile.am:336: warning: .INTERMEDIATE was already defined in condition !BUILD_DARWIN, which is included in condition TRUE ...
< phantomcircuit> Makefile.am:140: ... '.INTERMEDIATE' previously defined here
< phantomcircuit> from autogen.sh
< phantomcircuit> output
< fanquake> sounds very much like a local issue
< phantomcircuit> fanquake, it's literally a brand new debian 10
< phantomcircuit> sipa, fixes the autogen.sh warning but not the linker failure
< phantomcircuit> 0.20.1 works fine, i'll bisect
< phantomcircuit> nvm i spoke too soon
< phantomcircuit> fanquake, i dont think it's a local issue especially cause everything but building for fuzzing seems to work fine
< sipa> what debian version?
< phantomcircuit> sipa, 10.7
< phantomcircuit> sipa, exactly what i did
< fanquake> phantomcircuit: you're right. I've just seen the same with Clang 7. Don't have time to look into it now though.
< fanquake> How did our fuzz tests end up broken like this?
< fanquake> he
< fanquake> *heh
< phantomcircuit> fanquake, iono dont ask me :P
< sipa> works fine here
< sipa> clang 11.0.0-2
< fanquake> So it looks like the issue is actually with some older versions of clang and -fcf-protection=full
< fanquake> I can recreate the same ld output with a simple testcase
< fanquake> Don't see the issue with Clang 9. Haven't tested with 8.
< fanquake> Clang 8 also fine.
< fanquake> phantomcircuit: I don't understand why you don't see issues building normally, as that option would be present in both builds.
< fanquake> I've just built bitcoin-cli and see the same linking issue.
< phantomcircuit> fanquake, i guess because normal builds aren't using clang but gcc?
< fanquake> Right. I assumed you were using Clang all the time.
< bitcoin-git> [bitcoin] fanquake opened pull request #20720: build: more robustly check for fcf-protection support (master...more_robust_fcf_protection) https://github.com/bitcoin/bitcoin/pull/20720
< fanquake> phantomcircuit ^
< bitcoin-git> [bitcoin] hebasto closed pull request #20717: ci: Fix COMMIT_RANGE variable value for cloned repos (master...201218-clone) https://github.com/bitcoin/bitcoin/pull/20717
< bitcoin-git> [bitcoin] hebasto reopened pull request #20717: ci: Fix COMMIT_RANGE variable value for cloned repos (master...201218-clone) https://github.com/bitcoin/bitcoin/pull/20717
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #20717: ci: Fix COMMIT_RANGE variable value for cloned repos (master...201218-clone) https://github.com/bitcoin/bitcoin/pull/20717
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #20717: ci: Fix COMMIT_RANGE variable value for cloned repos (master...201218-clone) https://github.com/bitcoin/bitcoin/pull/20717
< bitcoin-git> [bitcoin] jnewbery opened pull request #20721: Net: Move ping data to net_processing (master...2020-12-ping-in-peer) https://github.com/bitcoin/bitcoin/pull/20721
< bitcoin-git> [bitcoin] laanwj closed pull request #20678: Add on autoconf as a dependency when building on macOS (master...autoconf-dependency) https://github.com/bitcoin/bitcoin/pull/20678
< jonatack> fuzzing with latest debian and clang version 9.0.1-15 is working for me
< bitcoin-git> [bitcoin] jonatack opened pull request #20723: p2p: improve logging in EvictExtraOutboundPeers() (master...improve-EvictExtraOutboundPeers-logging) https://github.com/bitcoin/bitcoin/pull/20723
< bitcoin-git> [bitcoin] hebasto closed pull request #20206: wallet, refactor: Include headers instead of function declarations (master...201020-headers) https://github.com/bitcoin/bitcoin/pull/20206
< bitcoin-git> [bitcoin] ajtowns opened pull request #20724: Cleanup of -debug=net log messages (master...202012-net-log-cleanup) https://github.com/bitcoin/bitcoin/pull/20724
< achow101> codesigning tool works!
< sipa> achow101: w0000t
< achow101> just need to write some docs and do the detached sig stuff we want
< bitcoin-git> [bitcoin] sdaftuar opened pull request #20726: p2p: Add BLOCKRELAY message for negotiating block-relay-only connection (master...2020-12-negotiate-block-relay) https://github.com/bitcoin/bitcoin/pull/20726