Honggfuzz exits unexpectedly about honggfuzz HOT 12 CLOSED

This happens as well when using radamsa as an external fuzzer.
The contents of wot.sh are:
wot.sh

root@IPHONE9:/home/javier/Fuzzing/Sessions/hongg_resolv_conf# cat ../wot.sh 
#!/bin/sh
echo "WOT" > $1

from honggfuzz.

With 810d2c9 I also implemented a fall-back mechanism for Linux.

If the glibc is safe-to-use (>=2.23), fork() is used. If not, clone() is used. clone() is not as good as safe-to-use fork(), but it's better than unsafe-fork().

In any case, using distro with glibc 2.24 or better is advised with honggfuzz.

from honggfuzz.

Hm... using "-f ." is tricky, as it will also pick up .honngfuzz files used for storing input files. Does it repeat with -f <some_external_file>

from honggfuzz.

Yes, still failed with.

./honggfuzz -f Testcases/resolvconf/ --covdir /tmp/testcoverage/ -s -n 1 -c /home/javier/Fuzzing/Sessions/wot.sh -- tee /tmp/tees

Errors again:

[2017-04-26T00:12:18+0100][E][32732] subproc_System():315 Command '/home/javier/Fuzzing/Sessions/wot.sh' terminated with signal: 11
[2017-04-26T00:12:18+0100][E][32732] fuzz_prepareFileExternally():146 Subprocess '/home/javier/Fuzzing/Sessions/wot.sh' returned abnormally
[2017-04-26T00:12:18+0100][F][32732] fuzz_fuzzLoop():537 fuzz_prepareFileExternally() failed

from honggfuzz.

Hm.. The command (wot.sh) files with SIGSEGV. It can be that it's actually our code after fork, but what do you have in wot.sh?

from honggfuzz.

I changed external file generation with some patches, could you try with the newest pull?

BTW: It's possible to use now both -f and -c. The external mutator will be used on files read from -f

from honggfuzz.

Still fails with freshly git pull'd and make'd build... I am starting to be suspicious that it can be something to do with my setup more than your (awesome) fuzzer.
The errors are still the same (exits with code SIGSEGV code 11).

Also when running with more than one thread it happens to have concurrency problems with the file [UNSET].
Shall I open a new issue for this or being that it is a problem of the same functionality (-c) report it here as well?

from honggfuzz.

I have similar issue for versions > 0.7.

I'm calling radamsa from within a custom bash script and it fails consistently. I'll provide more feedback once I gain access to my servers.

from honggfuzz.

I'm pretty certain it's this https://sourceware.org/bugzilla/show_bug.cgi?id=19431

Could you try running this with glibc-2.24 or newer (or glibc-2.23-ubuntu6 from Ubuntu) - Xenial should have it

from honggfuzz.

I can confirm it is not crashing anymore now! Thanks so much for the fix.
There is one little caveat now about cleanup: When stopping the fuzzer it will leave the following files:

-rw-r--r--  1 javier javier  2316 Jun  3 10:04 honggfuzz.input.0.fuzz
-rw-r--r--  1 javier javier  1320 Jun  3 10:04 honggfuzz.input.1.fuzz
-rw-r--r--  1 javier javier   378 Jun  3 10:04 honggfuzz.input.2.fuzz
-rw-r--r--  1 javier javier 31050 Jun  3 10:04 honggfuzz.input.3.fuzz

And since these files are there, the fuzzer won't run untill these are deleted.
Again, thanks for your time Robert, such an awesome job!

from honggfuzz.

Oh btw, for me it also works like a charm now. 👍

from honggfuzz.

And since these files are there, the fuzzer won't run untill these are deleted.

I've fixed the behavior in HEAD. The files should be generally deleted in fuzz_fuzzLoop() unless honggfuzz is killed with SIGKILL or so.

from honggfuzz.