`cargo ziggy run` should react if return code is not 0

[louismerlin]

@Ollrogge had the situation while fuzzing a C library that there was a segfault that made the binary return a non-zero return code, and a crash to be reported. But cargo ziggy run did not report this as a crash or that there was anything wrong with the seed. The runner should report non-0 codes, maybe even via crashing.

[Ollrogge]

To specify a little: Ziggy will stop running inputs when one of them crashes however there is no indicator what happened.

An example of running a binary that segfaults using cargo ziggy run and then running the runner manually:

cargo ziggy run -i ./test
    Building runner
   Compiling crash v0.1.0 (/home/nils/fuzzing/tests/crash)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.12s
    Finished runner
Now running file ./test
╭─nils@archlinux ~/fuzzing/tests/crash ‹master●› 
╰─$ echo $?                         
0
╭─nils@archlinux ~/fuzzing/tests/crash ‹master●› 
╰─$ ./target/runner/debug/crash test
Now running file test
[1]    150479 segmentation fault (core dumped)  ./target/runner/debug/crash test

[louismerlin]

@Ollrogge could you please check-out branch return-code?

The runner is trying to catch the segfault but somehow is not able to, maybe there is something that I'm missing.

[Ollrogge]

@Ollrogge could you please check-out branch return-code?

The runner is trying to catch the segfault but somehow is not able to, maybe there is something that I'm missing.

A segfault is a system-level fault and can therefore not be caught by Rusts catch_unwind. One possible approach would be to define a signal handler for commonlike shown here.

[louismerlin]

Non-0 exit codes and signals are now reported in cargo ziggy run thanks to @R9295's #114.

It's only a println with a "⚠️" for now though. #113, which I'm still working on, will have a run flag (-x) that will make the run stop at the first non-0 code it finds.

This issue should be resolved once #113 is merged, right @Ollrogge?

[R9295]

@louismerlin my PR does exactly that? Because the target will terminate anyways when signalled.
I think the issue here was that there was no information provided?

[louismerlin]

True true, with the current state of the code the inputs will stop running anyways, I'd forgotten that. Cool, we can close 🙌