testing: would be useful to record fuzz crashers which cause OOM kills #47572
Labels
fuzz
Issues related to native fuzzing support
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
n/a
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Tried out the new fuzzer on https://github.com/cixtor/binarycookies on this fork: https://github.com/stevenjohnstone/binarycookies/tree/sjj/beta_fuzz. Started with a very simple fuzzer with two test cases added to the corpus:
https://github.com/stevenjohnstone/binarycookies/commit/6ba73d0cab7dca809098da87fc32ac7a271691e1
Immediately finds out of memory bugs 🎉
I made some fixes (guided by the output above) and continued fuzzing. I then ran into bugs where the process is killed because of OOM: "fuzzing process terminated by unexpected signal; no crash will be recorded: signal: killed". Without a crash recorded, the information is reduced to "you have a memory bug".
I think OOM is encountered with this code in a couple of ways:
fmt.Errorf("%q", buf)
make
where the size is calculated by the difference of two unsigned ints a -b where a < bWhat did you expect to see?
I'd like to see crashes recorded for processes which are killed. Out of memory bugs resulting in the OS killing the process are critical as there's no panic to catch so can't be mitigated.
What did you see instead?
No crash recorded when the fuzzer encounters buggy code making huge memory allocations.
The text was updated successfully, but these errors were encountered: