We see some episodic
"failed to delete old crash texts: Call error 11: Deadline exceeded (timeout)"
errors in logs.
Deleting at most 10 bugs should be enough since we do this check
after adding each new crash.
Due to https://github.com/google/syzkaller/issues/316 there're too many
mmap() calls in the programs, and syzkaller is spending quite a bit of
time mutating them. Most of the time changing mmap() calls won't give
us new coverage, so let's not do it too often.
The new app is based on our experience with syz-dash
and is meant to supersede it. This app aims at full
automation of bug lifecycle: reporting, tracking updates,
closing fixed bugs.
The main differences are:
- this app has support for reporting bugs
either by email or using an arbitrary external reporting system
- this app tracks status of bugs
- this app captures more info about kernel builds
KVM_RUN ioctl must have arg set to 0, otherwise it returns EINVAL.
This can lead to syzkaller not able to generate a C repro.
Since arg value is undefined, it might have different values when
executing a program with syz-exeprog vs executing a compiled C repro.
After a change in syscall description the number of syscall arguments
might change and some of the programs in corpus get invalidated.
This change makes syzkaller to generate missing arguments when decoding a
program as an attempt to fix and keep more programs from corpus.
Add new "syzkaller_descriptions" config param that allows
to specify a dir with additional syscall descriptions
that will be copied on top of syzkaller checkout.
Dashboard needs to know when bug fixing commits reach
builders in order to fully close bugs.
Send commits that dashboard is interested in to dashboard.
- fix and reorder .PHONY targets
- `make all` now builds everything, to build only essentials run `make main`
- `make all-tools` rename to `make tools`
Sometimes we get truncated console output during repro.
The problem is that we start the console reading ssh command,
but do not wait for it to actually connect and start piping console.
Wait while the command actually starts piping console before
starting the target command.
json decoding behavior is somewhat surprising
(see // https://github.com/golang/go/issues/21092).
This behavior is especially easy to hit in tests
that reuse reply objects.
To avoid any surprises, we zero the reply.
We can't know the exact values of those sleeps in advance, they can be
different for different bugs. Making them random increases the chance that
the C repro executes with the right timings at some point.
Sometimes C reproducers don't work after the generic prog options were
simplified. This change makes syzkaller to try extracting a C repro before
simplifying prog options and after each simplification step. This gives
us more chance to generate a C reproducer.
If manager exits during start, it's hard to understand what happens.
Save the previous manager log as manager.log.old until we have a better solution.
Also log errors on 0 log level.
If manager is connected to dashboard it now does not save crashes.
Which means that when we save a repro the crash dir may not exist yet.
Create the dir when saving repros.
