| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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().
|
| |
|
|
|
|
|
|
|
| |
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.
|
