Was running ../run_both.sh bitcoin-core 3, but it failed.

...
[Log level 2] : 13:06:58 : Wrapping function sancov.module_ctor_8bit_counters.86728
[Log level 2] : 13:06:58 : Wrapping function event_listener_getbase
[Log level 2] : 13:06:58 : Wrapping function event_listener_getfd
[Log level 2] : 13:06:58 : Wrapping function event_listener_destroy
[Log level 2] : 13:06:58 : Wrapping function event_listener_disable
[Log level 2] : 13:06:58 : Wrapping function event_listener_enable
[Log level 2] : 13:06:58 : Wrapping function evconnlistener_set_error_cb
[Log level 2] : 13:06:58 : Wrapping function evconnlistener_set_cb
[Log level 2] : 13:06:58 : Wrapping function evconnlistener_get_base
[Log level 2] : 13:06:58 : Wrapping function evconnlistener_get_fd
[Log level 2] : 13:06:58 : Wrapping function evconnlistener_disable
[Log level 2] : 13:06:58 : Wrapping function evconnlistener_free
[Log level 2] : 13:06:58 : Wrapping function evconnlistener_new_bind
[Log level 2] : 13:06:58 : Wrapping function evconnlistener_new
[Log level 2] : 13:06:58 : Wrapping function listener_read_cb
[Log level 2] : 13:06:58 : Wrapping function evconnlistener_enable
[Log level 2] : 13:06:58 : Wrapping function sancov.module_ctor_8bit_counters.86775
[Log level 2] : 13:06:58 : Wrapping function evthread_posix_get_id
[Log level 2] : 13:06:58 : Wrapping function evthread_posix_cond_wait
[Log level 2] : 13:06:58 : Wrapping function pthread_cond_timedwait
[Log level 2] : 13:06:58 : Wrapping function pthread_cond_wait
[Log level 2] : 13:06:58 : Wrapping function evthread_posix_cond_signal
[Log level 2] : 13:06:58 : Wrapping function pthread_cond_broadcast
[Log level 2] : 13:06:58 : Wrapping function pthread_cond_signal
[Log level 2] : 13:06:58 : Wrapping function evthread_posix_cond_free
[Log level 2] : 13:06:58 : Wrapping function pthread_cond_destroy
[Log level 2] : 13:06:58 : Wrapping function evthread_posix_cond_alloc
[Log level 2] : 13:06:58 : Wrapping function pthread_cond_init
[Log level 2] : 13:06:58 : Wrapping function evthread_posix_unlock
[Log level 2] : 13:06:58 : Wrapping function evthread_posix_lock
[Log level 2] : 13:06:58 : Wrapping function pthread_mutex_trylock
[Log level 2] : 13:06:58 : Wrapping function evthread_posix_lock_free
[Log level 2] : 13:06:58 : Wrapping function evthread_posix_lock_alloc
[Log level 2] : 13:06:58 : Wrapping function evthread_use_pthreads
[Log level 2] : 13:06:58 : Wrapping function pthread_mutexattr_init
[Log level 2] : 13:06:58 : Wrapping function pthread_mutexattr_settype
[Log level 2] : 13:06:58 : Ended wrapping all functions
[Log level 1] : 13:06:59 : Finished introspector module
/usr/bin/ld.gold: fatal error: LLVM gold plugin: <unknown>:0: Undefined temporary symbol .Ltmp265928

clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [Makefile:6708: test/fuzz/fuzz] Error 1
make[2]: Leaving directory '/src/bitcoin-core/src'
make[1]: *** [Makefile:17510: all-recursive] Error 1
make[1]: Leaving directory '/src/bitcoin-core/src'
make: *** [Makefile:812: all-recursive] Error 1
ERROR:root:Building fuzzers failed.

Looking into bind9 fuzz report for dns_rdata_fromwire_text_fuzzer, I encounter multiple inconsistent/confusing entries in the calltree:

for example in calltree idx: 00539, the callsite link shows 352k hits, while the node in call tree is red. It is the same for calltree idx: 00088 with callsite link

Can it be because the coverage is reporting hits from other fuzz targets? If yes, then #62 can be the solution.

We should bump OSS-Fuzz as a reasonbly high number of changes has happened since last bump. There was a slight change in the way post-processing unit is called, so a few minor things need change in OSS-Fuzz besides bumping the LLVM number.

@Navidem @AdamKorcz do you have anything that you would like to complete before bumping on OSS-Fuzz side?

Current fuzz introspector reports seem to key fuzzers by the filename where the fuzzer is defined (e.g. https://oss-fuzz-introspector.storage.googleapis.com/zstd/inspector-report/20220220/fuzz_report.html#Fuzzer:-sequence_compression_api.c)

For closer integration with OSS-Fuzz and ClusterFuzz though, we'd like to be able to better map the binary names we see on OSS-Fuzz to these reports. @DavidKorczynski @AdamKorcz WDYT? Would it be possible to include the actual binary names in these reports and key on that instead?

@Navidem FYI

Making an issue of https://github.com/ossf/fuzz-introspector/pull/525#issuecomment-1302464937

oss_fuzz_integration/runner.py has a few features that are convenient for building and running fuzzers by way of oss-fuzz, including:

• automatically downloading public corpus, which can be used to construct full coverage reports
• run commands such as: python3 ../runner.py {coverage | introspector} proj_name exec_sec which will build fuzzers of proj_name with the default sanitizer, run the fuzzers for exec_sec seconds and then generate a coverage or introspector report.

The features are useful when improving fuzzers for a given project as it makes the workflow fast.

Some of these features would make sense to add to OSS-Fuzz, in particular coverage generation using public corpus, generation of fuzz introspector reports for a given project and also generation just coverage for a given project.

Currently if there is a main() function in the module, introspector pass is skipped.

Should this be the case all the time? There are at least 4 projects on OSS-Fuzz that fuzz introspector does not generate fuzz_report.html because of this check. Projects include: tmux, tarantool, libssh, libspectre

@DavidKorczynski WDYT?

It will be useful to employ the reachability data in a way that the user can lookup a function-of-interest to find out which recommended fuzz target may reach to the FOI.

It may be useful for devs to compare the improvements they made wrt calltree bitmap. Right now the only way to do this is to eyeball the colouring on the report.

Would it make sense to add a percentage value here?

Since merge of https://github.com/google/oss-fuzz/pull/7788, around 59 projects fail to build.

As I checked some including json, valijson, wabt, wolfssl, and znc, the error message is:

/usr/bin/ld.gold: fatal error: LLVM gold plugin: <unknown>:0: Undefined temporary symbol .LtmpXXXXX

C++ std::.. calls can be very noisy and likely aren't very useful to fuzzer developers. e.g. for leveldb: https://storage.googleapis.com/oss-fuzz-introspector/leveldb/inspector-report/20220316/calltree_view_0.html

@Navidem and I discussed this and thought that we should just exclude all of these from the calltree.

@DavidKorczynski @AdamKorcz WDYT?

Umbrella issue for minor jvm issues

• runtime coverage functions is above reachable functions
• urls is missing some parts (apache-commons-cli is an example), including .java

To make introspector more versatile it makes sense to accept control-flow collected by other ways and just load it in post-processing. One alternative to LTO is using sancov: https://clang.llvm.org/docs/SanitizerCoverage.html#tracing-control-flow

The goal is to drastically improve https://fuzz-introspector.readthedocs.io/en/latest/ to make it a standard page for getting information on fuzz-introspector

In particular:

• provide improved installation guides (e.g. for recently added languages)
• provide a number of tutorials on how to use fuzz introspector
• provide guides that show why the data in fuzz-introspector is useful
• provide instructions on how to use Fuzz Introspector from an OSS-Fuzz perspective
• more developer-friendly docs

The goal of fuzz introspector is by and large to make it easier to improve a fuzzing set up for a given software package. At the moment fuzz introspector only focuses on a single analysis, whereas, in order to determine if an improvement was successful one has to compare two fuzz introspector runs. As such, we should have some features that make it possible to compare fuzz introspector analyses and specifically make it easy to highlight improvements/regressions.

I noticed the TinyGltf project has a set of calls to ASAN routines. https://storage.googleapis.com/oss-fuzz-introspector/tinygltf/inspector-report/20221210/fuzz_report.html

This should not happen as we aim to exclude them from the frontends.

After the recent update of the JVM frontends code, the execution time and memory usage is increased significantly, which sometimes result in out of memory and stack overflow. Double check of the logic and settings are needed to ensure the code run in acceptable time and resources.