| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
We don't need it to hold it for the call to the externally supplied
callback.
|
| | |
|
| |
|
|
|
|
|
|
| |
After ensuring that a bug only affects the patched kernel, do one more
round of reproduction and (if successful) re-report the result.
This will ensure that, provided enough time, diff fuzzing results will
also have minimalistic C reproducers.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As pingQueue holds maximum 1 element, it's not a very good indicator of
whether there are more elements in the reproduction queue. If the first
few crashes happen to be no longer needed (which is quite likely when
reproduction loop is started long after we have begun to collect the
crashes), the loop becomes reactive - new reproductions will be started
only once new bugs are submitted to the queue.
Fix it by polling the queue until it returns nil. Add a test that
exposes the previously existing bug.
|
| |
|
|
|
|
|
|
|
| |
We already mention the scheduled and started reproductions, but if the
reproduction was not started intentionally, that makes the logs look
very confusing.
Print a log message if NeedRepro() returned false when we were to
actually start the reproduction.
|
| |
|
|
|
|
|
|
| |
When the context is cancelled, no one may be polling the pingQueue, yet
we write to it synchronously.
Wrap it in a select{} statement and add a test to ensure that the loop
reacts properly to the context cancellation.
|
| |
|
|
|
| |
If the context is cancelled, we need to make sure that the reproduction
process is aborted as well.
|
| |
|
|
|
|
| |
It used to race with Enqueue(), which made it more complicated to write
reproducible tests. Also, there's really no reason to separate
StartReproduction() and Loop().
|
| |
|
|
| |
Always check it before starting the actual reproduction.
|
| |
|
|
|
|
|
|
|
| |
First consider how many times we've tried to reproduce the crash, and
only then look at other criteria.
This will make the reproduction process more just since in the presence
of multiple crashes in the queue we will give at least one chance to a
wider range of different crashes.
|
| |
|
|
|
|
| |
It was processed incorrectly in the repro loop - we should have skipped
that crash and looked for another one, but we actually ignored its
return value.
|
|
|
This is a potentially reusable piece of functionality.
|
