Coverage data (resp. features) from crashing inputs.

[janphilg]

Dear developer/community,

at the moment, I try to figure out, why centipede or the runner doesn't deliver coverage feedback from inputs that crashes the target. My idea is to write a function similar to AFL's crash exploration mode. For that, I feed crashing inputs in centipede's corpus and use them as mutation basis. To decide, which mutation reaches the same or nearby code coverage of the feeded crash, I need the coverage information of the crashing inputs.
I took a look on the communication between centipede and the runner and saw, that they are using pipes. For some reason, the runner does not write coverage feedback in the execution results when the target crashes and/or centipede doesn't read this information from the pipe. Is that perhaps because the child proccess, which runs the target, crashes and cannot give back coverage data? Or is there another reason? I would greatly appreciate an answer or a hint.

[kcc]

The coverage information is passed from the runner (child process) to the engine (parent process)
after executing an input, not during, because the coverage data needs to be pre-processed.
When the runner crashes, the "after" code is not invoked.

It may be possible to "fix" this by intercepting all ways a process can crash, and passing the coverage to the engine there.
But it's a non-trivial amount of work.

The communication is not actually pipes, but shmem, but it's a minor implementation detail.

The code is in ExecuteInputsFromShmem:

    if (!StartSendingOutputsToEngine(outputs_blobseq)) break;

    RunOneInput(data.data(), data.size(), test_one_input_cb);

    if (!FinishSendingOutputsToEngine(outputs_blobseq)) break;

[janphilg]

Thank you very much for this information!