Open richinseattle opened 3 years ago
Backtrace:
[2021-01-25T09:57:23Z INFO symcc_fuzzing_helper] Running on input /tmp/afl_rar2/secondary/queue/id:002025,src:002019,time:8333074,op:havoc,rep:4,+cov
thread 'main' panicked at 'No exit code available for afl-showmap', src/symcc.rs:368:14
stack backtrace:
0: rust_begin_unwind
at /rustc/4253153db205251f72ea4493687a31e04a2a8ca0/library/std/src/panicking.rs:493:5
1: core::panicking::panic_fmt
at /rustc/4253153db205251f72ea4493687a31e04a2a8ca0/library/core/src/panicking.rs:92:14
2: core::option::expect_failed
at /rustc/4253153db205251f72ea4493687a31e04a2a8ca0/library/core/src/option.rs:1258:5
3: symcc_fuzzing_helper::symcc::AflConfig::run_showmap
4: symcc_fuzzing_helper::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Interesting, I wonder what would cause afl-showmap
to terminate without an exit code on a Linux system. Maybe it was killed with a signal? The Rust docs suggest that that might be the reason. Anyway, I agree that it makes sense to skip such cases - they seem to be rare enough.
symcc_fuzzing_helper
throws anexpect()
panic when it fails to match onafl_show_map_status
if I let it run long enough on several targets. I've yet to find a target that does not hit this exception eventually. I am not sure of the root cause, the harness will run for some number of hours before this occurs. There should be an attempt to handle this gracefully and restart the solving loop. When run directly without the harness, I've run symqemu for 14 hours until memory limits were hit.https://github.com/eurecom-s3/symcc/blob/master/util/symcc_fuzzing_helper/src/symcc.rs#L368
running the below afl-showmap command that would have presumably run terminates normally with code 0