cargo-fuzz icon indicating copy to clipboard operation
cargo-fuzz copied to clipboard

Debug output not printed in repro-mode

Open nathaniel-brough opened this issue 2 years ago • 1 comments

Take a simple fuzz harness e.g.

#![no_main]

use arbitrary::Arbitrary;
use libfuzzer_sys::fuzz_target;

#[derive(Debug, Arbitrary)]
struct Ctx {
    foo: u8,
    bar: String,
}

fuzz_target!(|c: Ctx| {
    // Let's just make it crash.
    assert!(c.bar.len() > (c.foo as usize));
});

When I run this fuzzer and it crashes I get the following message printed;

Failing input:

        artifacts/fuzz_target_1/crash-adc83b19e793491b1c6ea0fd8b46cd9f32e592fc

Output of `std::fmt::Debug`:

        Ctx {
            foo: 10,
            bar: "",
        }

Reproduce with:

        cargo fuzz run fuzz_target_1 artifacts/fuzz_target_1/crash-adc83b19e793491b1c6ea0fd8b46cd9f32e592fc

Minimize test case with:

        cargo fuzz tmin fuzz_target_1 artifacts/fuzz_target_1/crash-adc83b19e793491b1c6ea0fd8b46cd9f32e592fc

However when I run the reproduction command I'll get something like this;

$ cargo fuzz run fuzz_target_1 artifacts/fuzz_target_1/crash-adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 880669544
INFO: Loaded 1 modules   (7173 inline 8-bit counters): 7173 [0x55843e82bb10, 0x55843e82d715), 
INFO: Loaded 1 PC tables (7173 PCs): 7173 [0x55843e82d718,0x55843e849768), 
target/x86_64-unknown-linux-gnu/release/fuzz_target_1: Running 1 inputs 1 time(s) each.
Running: artifacts/fuzz_target_1/crash-adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
thread '<unnamed>' panicked at fuzz_targets/fuzz_target_1.rs:14:5:
assertion failed: c.bar.len() > (c.foo as usize)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
==471585== ERROR: libFuzzer: deadly signal
    #0 0x55843e62a5b1  (/home/nathaniel/fuzz_debug/fuzz/target/x86_64-unknown-linux-gnu/release/fuzz_target_1+0xf95b1)
    #1 0x55843e68c5d9  (/home/nathaniel/fuzz_debug/fuzz/target/x86_64-unknown-linux-gnu/release/fuzz_target_1+0x15b5d9)
    #2 0x55843e6779a5  (/home/nathaniel/fuzz_debug/fuzz/target/x86_64-unknown-linux-gnu/release/fuzz_target_1+0x1469a5)
    #3 0x7fd45df71d9f  (/nix/store/whypqfa83z4bsn43n4byvmw80n4mg3r8-glibc-2.37-45/lib/libc.so.6+0x38d9f) (BuildId: 2b9ebcc534a497a5e424c017f310e087ec14b7b6)
# Truncated ...

Notably I don't get the Debug print as earlier. This is kind of painful as I'll often get a minimized test-case from somewhere like google/oss-fuzz and I can't see the original debug statement. My workaround at the moment is to put a println!() statement in when I'm reproduces a bug and delete it later. Note that I have tried to conditionally print using the fuzzing_repro config as described in the cargo-fuzz book. But that doesn't seem to print anything at all even in repro mode?

#[cfg(fuzzing_repro)]
eprintln!("Input data: {}", expensive_pretty_print(&data));

Any thought's on how to best manage this? I feel like I'm missing something important.

nathaniel-brough avatar Dec 02 '23 18:12 nathaniel-brough

cargo fuzz fmt fuzz_target_1 artifacts/fuzz_target_1/crash-adc83b19e793491b1c6ea0fd8b46cd9f32e592fc will print the failing input. Which might be useful workaround for now.

Eh2406 avatar Jan 07 '24 17:01 Eh2406