Panic causes fuzzing cessation

[bookmoons]

If my fuzz function panics, it seems to cause cessation of all fuzzing. Output starts showing execs: 0 (0/sec). Not sure if that's the expected behavior or not. I was imagining it would log the panic as a crash then keep mutating.

pineapple has a test case.

package pineapple

func Fuzz(input []byte) int {
	panic("tried to eat a pinecone")
}

go-fuzz-build && go-fuzz -v=4

2019/08/22 20:23:28 worker 0 triages coordinator input [0][218 57 163 238 94 107 75 13 50 85 191 239 149 96 24 144 175 216 7 9] minimized=true smashed=true
2019/08/22 20:23:28 worker 0: triageq=0 execs=0 mininp=0 mincrash=0 triage=1 fuzz=0 versifier=0 smash=0 sonar=0 hint=0
2019/08/22 20:23:28 testee: panic: tried to eat a pinecone

goroutine 1 [running]:
github.com/bookmoons/pineapple.Fuzz(0x7e8337694000, 0x0, 0x0, 0x4)
	/home/user/go/src/github.com/bookmoons/pineapple/pineapple_fuzz.go:4 +0x51
go-fuzz-dep.Main(0xc00007cf80, 0x1, 0x1)
	/tmp/go-fuzz-build984651294/goroot/src/go-fuzz-dep/main.go:36 +0x1b6
main.main()
	/tmp/go-fuzz-build984651294/gopath/src/github.com/bookmoons/pineapple/go.fuzz.main/main.go:15 +0x52

2019/08/22 20:23:28 testee: 
2019/08/22 20:23:28 worker 0 processes crasher [0][218 57 163 238 94 107 75 13 50 85 191 239 149 96 24 144 175 216 7 9]
2019/08/22 20:23:30 workers: 2, corpus: 1 (3s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 3s
2019/08/22 20:23:31 hub: corpus=0 bootstrap=0 fuzz=0 minimize=0 versifier=0 smash=0 sonar=0
2019/08/22 20:23:33 workers: 2, corpus: 1 (6s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 6s
2019/08/22 20:23:34 hub: corpus=0 bootstrap=0 fuzz=0 minimize=0 versifier=0 smash=0 sonar=0
2019/08/22 20:23:36 workers: 2, corpus: 1 (9s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 9s
2019/08/22 20:23:37 hub: corpus=0 bootstrap=0 fuzz=0 minimize=0 versifier=0 smash=0 sonar=0
2019/08/22 20:23:39 workers: 2, corpus: 1 (12s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 12s
2019/08/22 20:23:40 hub: corpus=0 bootstrap=0 fuzz=0 minimize=0 versifier=0 smash=0 sonar=0

It never seems to pick back up:

go-fuzz

2019/08/22 20:27:09 workers: 2, corpus: 1 (3s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 3s
2019/08/22 20:27:12 workers: 2, corpus: 1 (6s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 6s
2019/08/22 20:27:15 workers: 2, corpus: 1 (9s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 9s
2019/08/22 20:27:18 workers: 2, corpus: 1 (12s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 12s
2019/08/22 20:27:21 workers: 2, corpus: 1 (15s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 15s
2019/08/22 20:27:24 workers: 2, corpus: 1 (18s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 18s
2019/08/22 20:27:27 workers: 2, corpus: 1 (21s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 21s
2019/08/22 20:27:30 workers: 2, corpus: 1 (24s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 24s
2019/08/22 20:27:33 workers: 2, corpus: 1 (27s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 27s
2019/08/22 20:27:36 workers: 2, corpus: 1 (30s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 30s
2019/08/22 20:27:39 workers: 2, corpus: 1 (33s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 33s
2019/08/22 20:27:42 workers: 2, corpus: 1 (36s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 36s
2019/08/22 20:27:45 workers: 2, corpus: 1 (39s ago), crashers: 1, restarts: 1/0, execs: 0 (0/sec), cover: 0, uptime: 39s

[josharian]

I am AFK for a while, it if you want to dig into this, it’d be useful to know whether this is a recent regression. Note that any time you change go-fuzz version you must also rebuild go-fuzz-build and rebuild your fuzz zip.

[bookmoons]

Tried it with this commit from January and it still happens:
9db3bd8

I rebuilt go-fuzz and go-fuzz-build then built a new fuzzer.

[bookmoons]

Noticed the panic ends up in suppressions.

panic: tried to eat a pinecone
github.com/bookmoons/pineapple.Fuzz
go-fuzz-dep.Main
main.main

[tdewolff]

My experience: as soon as the fuzzer finds a panic, it always greatly decreases the execs/sec for me. I usually stop it and fix the bug. This has been like this for years for me with go-fuzz. Perhaps continuing to run the fuzzer it might eventually get over it, but I never tried that.

[ThorbjoernSchulz]

The problem is that the corpus inputs never reach the hub, the component that makes shared resources available to the workers. Initially corpus inputs go into a triage queue where they are tested with the target program. After this the inputs are fed to the hub. However if the program panics on these test inputs they don't reach the hub. There is even a comment in the code that says that you shouldn't provide crashing inputs in the initial corpus.
The coordinator and the workers are still running, thus the output. But they never get to do anything because there are no inputs.
In this case your program always panics so it makes no difference - even with the default input it crashes.

So I will investigate how to mitigate this. Because crashing inputs alone do not necessarily lead to this behavior. It appears that you need a lot of subsequent crashes until the fuzzer "gives up". I'm not sure yet when this point is reached.

EDIT: Ok, I think know what to do. I will try to provide a pull request until the end of the day.