Multiprocess fuzzing will not be supported by the libFuzzer maintainers. Fuchsia has implemented a new approach with their Component Fuzzing Framework (RFC-117).

Multiprocess fuzzing will not be supported by the libFuzzer maintainers. Fuchsia has implemented a new approach with their Component Fuzzing Framework (RFC-117).

Multiprocess fuzzing will not be supported by the libFuzzer maintainers. Fuchsia has implemented a new approach with their Component Fuzzing Framework (RFC-117).

Multiprocess fuzzing will not be supported by the libFuzzer maintainers. Fuchsia has implemented a new approach with their Component Fuzzing Framework (RFC-117).

Multiprocess fuzzing will not be supported by the libFuzzer maintainers. Fuchsia has implemented a new approach with their Component Fuzzing Framework (RFC-117).

Multiprocess fuzzing will not be supported by the libFuzzer maintainers. Fuchsia has implemented a new approach with their Component Fuzzing Framework (RFC-117).

Multiprocess fuzzing will not be supported by the libFuzzer maintainers. Fuchsia has implemented a new approach with their Component Fuzzing Framework (RFC-117).

Multiprocess fuzzing will not be supported by the libFuzzer maintainers. Fuchsia has implemented a new approach with their Component Fuzzing Framework (RFC-117).

Multiprocess fuzzing will not be supported by the libFuzzer maintainers. Fuchsia has implemented a new approach with their Component Fuzzing Framework (RFC-117).

Multiprocess fuzzing will not be supported by the libFuzzer maintainers. Fuchsia has implemented a new approach with their Component Fuzzing Framework (RFC-117).

Multiprocess fuzzing will not be supported by the libFuzzer maintainers. Fuchsia has implemented a new approach with their Component Fuzzing Framework (RFC-117).

Multiprocess fuzzing will not be supported by the libFuzzer maintainers. Fuchsia has implemented a new approach with their Component Fuzzing Framework (RFC-117).

Multiprocess fuzzing will not be supported by the libFuzzer maintainers. Fuchsia has implemented a new approach with their Component Fuzzing Framework (RFC-117).

Multiprocess fuzzing will not be supported by the libFuzzer maintainers. Fuchsia has implemented a new approach with their Component Fuzzing Framework (RFC-117).

Multiprocess fuzzing will not be supported by the libFuzzer maintainers. Fuchsia has implemented a new approach with their Component Fuzzing Framework (RFC-117).

Multiprocess fuzzing will not be supported by the libFuzzer maintainers. Fuchsia has implemented a new approach with their Component Fuzzing Framework (RFC-117).

Multiprocess fuzzing will not be supported by the libFuzzer maintainers. Fuchsia has implemented a new approach with their Component Fuzzing Framework (RFC-117).

Update: I'm still having trouble reproducing the Windows-only failure in a handful of integration tests. I'm de-prioritizing this just a bit on my end as it's not strictly necessary for a near-term demo. I will return and figure the Windows issue out, though, as it *is* necessary to land this change and make it available to Fuchsia downstream.

Okay, so after return from a few weeks vacation, I've tried to examine the three tests that failed earlier in detail. I added counters for additions to the TORCs, MMT, and ValueProfileMap to ensure no signal was being lost, and compared the log of successful mutation sequences before and after the change.

The previous patch was a long-shot to try to get clang-tidy to find clang/clang.h. It didn't work, so there's no reason to modify tests/CMakeLists.txt. The patch reverts it.

Add no-sanitize-all to from* functions.

Original revision reopened instead.

Fixed an issue with msan function pointers being uninitialized.

Added some feature macros to detect msan and include msan_interface properly for the standalone build.

I have to hit pause on this. While the normal cmake approach passes, I just noticed the standalone approach to building the unit test doesn't.

In D102447#2777667, @morehouse wrote:

Please remove libMutagen.a from the diff before landing since we don't have libFuzzer.a in the current tree either.

3 out of the 4 lines clang-tidy complains about match what's in other source files on main; this change addresses the last one.

See comments on D94512 and D94514. This revision no longer descends from D94508 or D94509 as we no longer need fuzzer::ModuleRelativeValues or the changes to FuzzerFork.cpp.

Moved the ModuleInfo struct from FuzzerModuleRelative.h to FuzzerTracePC.h and added MoudleInfoByHash. Along with the decision in D94514 to not support relative features when -fork=1, this obviates the need for D94508 and D94509.

Fine with me if it reduces performance issues.

I'm playing a bit with a version that introduces new markers: "FT_REL" and "COV_REL". I'll finish that up soon, post it, and collect some more perf numbers.

Crud... I just noticed the .o files. New diff incoming...

Regarding performance: I added some microbenchmarks in Merger::Parse and Fuzzer::CrashResistantMergeInternalStep around the parts that use ModuleRelativeValues objects. I then ran 1000 iterations of a test based on the first non-empty merge in compiler-rt/test/fuzzer/merge.test.

Changed DsoInfo to ModuleInfo (and changed PrintModuleInfo to PrintModuleSummary). Moved asserts in CollectFeatures to unit tests.

Renamed DSO -> Module to be more in keeping with LLVM. Fixed a bug in calculating features that caused tests to fail when run with sanitizer instrumentation.

In D94517#2612598, @morehouse wrote:

Sorry if I'm misunderstanding the design. But how will we prevent stack trace skew from signals being delivered asynchronously?

i.e. We need a stack trace *now*, so we send a signal to that process. But by the time that process receives the signal, the IP is somewhere else, maybe a different function. So our stack trace is wrong.

In D94517#2604034, @morehouse wrote:

Interface change LGTM.

For the PID stuff, what is the plan for process-specific reports? To send a signal to the specified process to get a stack trace/memory profile?

fyi: I'd like D97992 to land first; and for this change to be rebased on top of that.

Fixed indent added by clang-format.

Changed SumIncidence's type to double to reduce a lot of superfluous static_casting back a forth.

Added a comment to the static_assert to make it -std=c++11 compatible.

Addressed (most of) morehouse's comments. I still need to measure performance impact.

Addressing morehouse's comments. Also adjusted size and stack depth functions in TracePC to address some concerns that are in the following change (D94514), but are rleated to files and functions being changed here.

Note to reviewers: this still has a lot of test disabled as FIXMEs. While the preceding changes are in review, I hope to investigate and rectify some of these. Others require additional features to be added that I won't try to land ahead of this change, e.g. value-profile support.