Open bluescreen303 opened 3 years ago
I'm getting the same result (plus backtrace and 2 panic messages) with cargo run
. How can I reproduce this?
I'm able to reproduce with the steps provided. I think this is an artifact of how output is captured. If you run cargo test -- --nocapture
, you should get the equivalent output as cargo run
. The test harness doesn't have the opportunity to report the original panic because of the panic-in-panic causes the process to terminate too early.
I'm getting the same result (plus backtrace and 2 panic messages) with
cargo run
. How can I reproduce this?
Copying and pasting their example directly into the playground and just clicking "test" without changing any settings at all seems to give the sigill
error.
This issue is bothering me too.
To be clear the real annoyance here isnt that a sigill occurs, its that we cant see the tracktraces and panic messages when doing cargo test
.
But we can see the stack traces just fine when doing cargo run
.
It occurs on any double panic, so a simpler way to reproduce this is:
struct PanicOnDrop {
}
impl Drop for PanicOnDrop {
fn drop(&mut self) {
panic!("dropped");
}
}
fn main() {
let _panic_on_drop = PanicOnDrop { };
panic!("first panic!");
}
#[cfg(test)]
mod tests {
use main;
#[test]
fn foo() {
main();
}
}
As mentioned by ehuss cargo test --nocapture
works around the issue, but I think it is a bug that we cannot see the stacktraces without knowing to use this magic flag.
I just hit this issue debugging a flaky CI failure in one of my tests. It's very unfortunate that the backtrace is lost in this case. Could libtest be installing a panic hook that bypasses output capturing if the panic is going to lead to an abort?
I tried this code:
running this with
cargo run
works fine. I get an assertion failure because 1 isn't 2.But when I run
cargo test
I expected to see this happen:
assertion failure because 1 isn't 2
Instead, this happened:
Meta
rustc --version --verbose
: