Crash analysis - more info about crash in/from LibAFL

[marcinguy]

Wrote a harness to fuzz a lib using LibAFL.

I get a crash within LibAFL, but cannot reproduce it outside LibAFL (almost identical harness ... outside LibAFL I added just main() function)

Would be great if LibAFL could save stacktrace, registers along the crashfile etc during the observed crash to debug it.

Could be that it is an issue in my harness or LibAFL.

Having this info would help to debug issues with harnesses, also for other projects and other users.

Thanks,

P.S Cool project

[vanhauser-thc]

Hi Marcin! are you using libaflfuzzer.a ? If a crash is not reproducible it is most likely that there is a) a race condition in the target or b) increased resource usage that is not freed that lead to a crash. Please note that basically any other fuzzer out there is currently better, as a lot of important features are missing. We are still experimenting with the API before we do the heavy lifting.

[marcinguy]

@vanhauser-thc yes, libaflfuzzer.a

I lean towards a)

Weird is that paths don't increase also. Crashes, few, always happen at the beginning.

Fuzzing with similar harness in aflpp and libfuzzer paths do increase.

A way to start fuzzer in some mode, since I can imagine it can be perf kill, to get more info about crash would be great. This can help in building harnesses, debug this kind of issues. Wdyt?