Re-producing a crash

[kernelGadaffi]

Hi,

I have obtained about a handful of crashes from grinder when I fuzz Safari on windows using the nduja fuzzer. However, when I run the testcase.rb using the .log file in the crashes folder, the html file generated did not re-produce the crash. How do we modify the grinder framework to get all non-crashing test cases generated before up to the one that crash? Could it be a cumulative effect of a few test cases causing the crash instead thanks.

[kernelGadaffi]

Ok its alright I found them in the C:\Users\$USER$\ AppData\Local\Temp\Low

[stephenfewer]

The crashes located in $logger_dir are not the linear sequence of testcases generated up until a crash. Each log file is unique for a process being fuzzed (named with the PID of the process) and every new testcase run in that process overwrites the last one in the log file. So you will only ever get the last testcase run.

If you take a look at \grinder\node\source\logger\logger.c, you can see LOGGER_finishedTest closes the file handle so the next time a log message comes in (LOGGER_startingTest) the log file is overwritten for the new testcase.

If you remove the Javascript line in the fuzzer to "logger.finished();" then this will not happen. Alternatively you could modify the browsers hooking stub; e.g. for IE \grinder\node\browser\internetexplorer.rb creates an asm stub which can call @attached[pid].finishedtest to close the log file and for the next testcase to overwrite it. Commenting out this call will stop the last testcase from being overwritten.

However, your best bet to help reproducing testcase which don't reproduce are as follows:

• Create an alert in the Grinder Server to catch new crashes which match the one your interested in. It can happen that a new testcase for the same crash will reproduce where the older one will not.
• Manually go through the fuzzer to ensure it is logging accurate information. Every operation preformed by the fuzzer needs to be logged. It is also important to get logging working correctly in situations such as event callbacks, which need to execute the generated javascript in the callback itself (depending how the fuzzer performs logging, this assumption may not be true).

I have found that, with a little work ensuring the fuzzer logs correctly, test cases nearly always reproduce.