libafl_libfuzzer crash output is extremely verbose compared to libFuzzer

[mschwager]

Note this issue originated as PR #3735.

When using libafl_libfuzzer_runtime in libFuzzer compatibility mode, a crash detected by ASan produces megabytes of output that doesn't appear in standard libFuzzer. The extra output comes from generate_minibsod() being called unconditionally in inproc_crash_handler.

For an ASan-detected heap-use-after-free, standard libFuzzer output is:

• ASan report (~60 lines)
• artifact_prefix line with crash file path

LibAFL's libfuzzer compatibility mode produces:

• ASan report (~60 lines)
• DEBUG: inproc_crash_handler enter
• Crashed with SIGABRT / Child crashed!
• Full Rust backtrace via Backtrace::force_capture() (~2MB of LibAFL/Rust internals)
• Register dump
• /proc/self/maps (~375 lines)
• Objective summary

E.g.

==9==ABORTING
DEBUG: inproc_crash_handler enter
[2026-04-08T11:47:08Z ERROR libafl::executors::hooks::unix::unix_signal_handler] Crashed with SIGABRT
[2026-04-08T11:47:08Z ERROR libafl::executors::hooks::unix::unix_signal_handler] Child crashed!
[2026-04-08T11:47:09Z ERROR libafl::executors::hooks::unix::unix_signal_handler] input: "0f0b2ade69d094fc"
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CRASH ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    Received signal SIGABRT at 0x0000ffff91ed3c18, fault address: 0x0000000000000000
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ REGISTERS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    x00: 0x0000000000000000 x01: 0x0000000000000009 x02: 0x0000000000000006 x03: 0x0000ffff97172020 
    x04: 0x0000ffff97184b98 x05: 0x0000000000000001 x06: 0x0000000000000020 x07: 0x0000000000000000 
    x08: 0x0000000000000083 x09: 0x0000ffff93494c28 x10: 0x0000000000000000 x11: 0x0000000000000000 
    x12: 0x000000000000003d x13: 0x00000000003c47b5 x14: 0x0000000000000008 x15: 0x0000000000000010 
    x16: 0x0000000000000001 x17: 0x0000ffff934b11e8 x18: 0x0000000000000010 x19: 0x0000000000000009 
    x20: 0x0000ffff97172020 x21: 0x0000000000000006 x22: 0x0000000000000000 x23: 0xafffff00000fffff 
    x24: 0x0000ffff9682e8e8 x25: 0xffffff0000000000 x26: 0x0000ffff9675c000 x27: 0x10000000000fffff 
    x28: 0x0000010000000000 x29: 0x0000ffffeb247e60 x30: 0x0000ffff91ed3c04 pc : 0x0000ffff91ed3c18 
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    < 2MB of backtrace info >
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ MAPS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    < Hundreds of lines of memory info >

The Rust backtrace in particular is problematic: minibsod uses Backtrace::force_capture(), which ignores RUST_BACKTRACE=0, so users have no way to suppress it.

For the libFuzzer compatibility use case, the minibsod output is not particularly useful. The ASan report already contains the relevant stack trace, and the register dump / memory maps are debugging info for the fuzzer internals, not the target. This degrades the user experience compared to standard libFuzzer.

Some possible approaches:

• Gate the generate_minibsod call in inproc_crash_handler behind an option or environment variable
• Have libafl_libfuzzer_runtime configure the executor to skip minibsod output in libfuzzer compatibility mode
• Add a verbosity level to the crash handler so users can opt into the full diagnostic output when needed

[kx7m2qd]

Hi @mschwager, I'd like to work on this. I'm thinking of gating the generate_minibsod() call in inproc_crash_handler behind an environment variable like LIBAFL_MINIBSOD — so it's opt-in rather than default. For libafl_libfuzzer_runtime in compatibility mode, it would be disabled by default to match standard libFuzzer behaviour. Does this approach align with what you had in mind?