| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a "fatal error:" bug is reported, this usually means that syzkaller
itself had a memory corruption (except in the gVisor fuzzing case where
this could be an actual bug in gVisor)
Most likely, this is due to a kernel that went wild and corrupted the
syzkaller address space, but in that case the exact details of what part
of the runtime failed are rarely relevant.
This gathers all these go runtime errors under one umbrella so they are
easier to track. Except for gVisor on which the logic is kept the same
as existing.
Add three test cases to the linux reporting:
- 705 (equivalent to the current all/report/7) to make sure Go OOO are
suppressed (they have a different title now but still get suppressed)
- 706 (equivalent to the current all/report/8) to make sure that ALSA
"fatal errors" are not handled as Go fatal errors
- 707 (new) to make sure that reports like
https://syzkaller.appspot.com/bug?extid=3f00d7083c52713ba3b0 are
re-named to "go runtime error"
|
| |
|
|
| |
It refers to SYZFAIL and SYZFATAL errors.
|
| |
|
|
|
| |
Of course something in the kernel prints "fatal error"
and it's not a kernel bug.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This several small improvements:
1. Move these patterns into the common part.
We run Go code on (almost) all OSes and error messages
are the same for all of them.
2. Detect "fatal error:" as a bug as well.
This is what I currently see from Go 1.20 runtime,
but we don't recognize it, so these reports probably
go into "lost connection" bucket now (bad).
3. Add a pattern for panic(ENOMEM) message.
pkg/image/compression_optimized.go can produce it
on mmap failure.
4. Add tests.
|
| |
|
|
| |
Signed-off-by: Andrei Vagin <avagin@google.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Replace not just long sequences of digits in report titles, but every
sequence of '0'-'9' that is not surrounded by word characters.
As such matches will overlap and Go does not (currently?) support regexp
lookarounds, do the replacement multiple times until there is nothing
more to do. This should not slow down syzkaller, since this code is
only invoked during crash processing.
Restrict LINE replacement only to fragments that have a preceeding file
name. This prevents replacements like [1:2] -> [NUM:LINE].
|
|
|
Some syzkaller panics happen due to memory corruptions,
but it still would be useful at least to get some visibility into these crashes.
On some OSes we actualy already detect them as they have "panic:" oops pattern,
but not e.g. on linux.
Fixes #318
|
