You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a thread panics in a Shuttle test, generator produces an error that gets printed to stdout via tracing. This error is a red herring: it mentions generator::gen_impl and so suggests that maybe something went wrong in that code, when really it's just that a Shuttle thread panicked and that panic is being propagated. It would be nice to suppress this error so we don't lead users down the wrong debugging path.
The text was updated successfully, but these errors were encountered:
I have a Shuttle test running inside a proptest, where a failing execution aborts before showing the input used by proptest (and probably even before proptest tries to minimize).
After the stack backtrace the output finishes as follows:
Aug 12 11:16:32.499 ERROR generator::gen_impl: set panicked inside generator
thread panicked while panicking. aborting.
error: test failed, to rerun pass '-p foo --lib'
Caused by:
process didn't exit successfully: `/path/to/foo-7e20baac4e3ab4e7 'foo:bar' --exact --nocapture` (signal: 4, SIGILL: illegal instruction)
Will suppressing the generator error resolve the nested panicking and SIGILL?
No, the generator error is only an error message printed when the Shuttle thread is panicking -- it doesn't actually create its own panic. Nested panics like this usually happen because a Drop handler panics during stack unwinding. We could consider creating an option to disable stack unwinding after a panic (by leaking the generator threads) to make minimization work.
When a thread panics in a Shuttle test,
generator
produces an error that gets printed to stdout viatracing
. This error is a red herring: it mentionsgenerator::gen_impl
and so suggests that maybe something went wrong in that code, when really it's just that a Shuttle thread panicked and that panic is being propagated. It would be nice to suppress this error so we don't lead users down the wrong debugging path.The text was updated successfully, but these errors were encountered: