More shrinking! #39
More shrinking! #39
Conversation
… that was successfully shrunk
…is relevant to which shrinking strategy
| assert(sv->later_time != NO_EVENT_SCHEDULED); | ||
| sv->later_time = NO_EVENT_SCHEDULED; | ||
| dequeue_event(event_queue, &event_queue_len, idx); | ||
| if(sv->later_time != NO_EVENT_SCHEDULED) { |
There was a problem hiding this comment.
Under what circumstances does this check become necessary?
There was a problem hiding this comment.
If you are trying to dequeue an event on a variable that has no future event scheduled for it, this function will look for it in the queue, not find the index of it and then ASSERT(QUEUE_HEAD <= idx) will fail.
There was a problem hiding this comment.
I noticed this since the assertion would fail in a lot of the generated test programs, but because we did not inspect stderr to find out if execution succeeded well, we didn't notice it.
There was a problem hiding this comment.
we shouldn't even be using these assertions in the first place, since as you observed, these don't convey the right information to the debug harness. We should replace these with our own assertion macros that print out messages the trace parser can understand.
There was a problem hiding this comment.
I presume this check/assertion only fails when a process exits while updates are still scheduled for its local variables; we should add a comment to indicate that.
Given the invariant that all events not in the queue have later_time set to NO_EVENT_SCHEDULED, this is functionally equivalent to checking that the return value of index_of_event is non-zero, but a lot more efficient. We should make this clear in the comment.
|
adding note that this fixes #31 |
Fingers crossed that we'll get some nice, small test-cases now! Please let me know as soon as you find any test case which you see could have been shrunk more, and I'll try to add strategies to match these specific instances. |
Rewrote some of the shrinking strategies to reuse more code & shrink more stuff. There's also 2 bug-fixes to the runtime system here.
I split the shrinking up into several modules (one module per shrinking strategy). This, imo, makes it easier to get an overview of how each shrinking strategy is implemented. It helped me debug some of them while I was doing this.