panic in main

[onelson]

I can't explain it, but thought I'd post an issue in case this is something you'd come across before.
cargo test-junit fails with a panic when I run it as part of a build step in a docker container.

Any ideas?

Step 6 : RUN cargo test-junit --name test-report
 ---> Running in 77ae59c9b724
thread 'main' panicked at 'Parser error', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-test-junit-0.6.1/src/main.rs:45
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: cargo_test_junit::main

[onelson]

Full backtrace indicates https://github.com/rustation/cargo-test-junit/blob/master/src/main.rs#L43
I'll probably have to work around the stream handling to get this to work for me. Maybe I'll have to do this as a post-build step (which I'd prefer not to) so I can use docker run --tty to get stdout to not panic.

Step 6 : RUN cargo test-junit --name test-report
 ---> Running in 78d228b2abbd
thread 'main' panicked at 'Parser error', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-test-junit-0.6.1/src/main.rs:45
stack backtrace:
   0:     0x56326b330bc3 - std::sys::imp::backtrace::tracing::imp::unwind_backtrace::hab274209b3900f9c
                               at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1:     0x56326b32ce24 - std::sys_common::backtrace::_print::h8f655fc4b25b9b70
                               at /checkout/src/libstd/sys_common/backtrace.rs:71
   2:     0x56326b335ac7 - std::panicking::default_hook::{{closure}}::hd0f0fde26cdd4a91
                               at /checkout/src/libstd/sys_common/backtrace.rs:60
                               at /checkout/src/libstd/panicking.rs:355
   3:     0x56326b33567c - std::panicking::default_hook::h123df66825ae8c79
                               at /checkout/src/libstd/panicking.rs:371
   4:     0x56326b335f9b - std::panicking::rust_panic_with_hook::h3635757261b59272
                               at /checkout/src/libstd/panicking.rs:549
   5:     0x56326b29272f - std::panicking::begin_panic::h46d3207214572fc9
   6:     0x56326b298fa6 - cargo_test_junit::main::h8c4a99bfbef70169
   7:     0x56326b33ce3a - __rust_maybe_catch_panic
                               at /checkout/src/libpanic_unwind/lib.rs:98
   8:     0x56326b33673a - std::rt::lang_start::ha5350a26f8f175ab
                               at /checkout/src/libstd/panicking.rs:433
                               at /checkout/src/libstd/panic.rs:361
                               at /checkout/src/libstd/rt.rs:57
   9:     0x7f8297143b44 - __libc_start_main
  10:     0x56326b291c99 - <unknown>
  11:                0x0 - <unknown>
The command '/bin/sh -c cargo test-junit --name test-report' returned a non-zero code: 101

[onelson]

So, I switched the build to use cargo directly in the jenkins slave, but I am sometimes getting this error, and sometimes not.
I assume this is some issue with a dependency, duct maybe?

I think for now, I'm just going to run cargo test --message-format=json and write a small converter to push the output through in the shell itself. Welp. Switching the message format is next to useless. It doesn't really wrap up the test data. I get it now. This is all terrible.

[jgrund]

Hi,

If I remember correctly, there is something in the raw test output that is non-deterministic.

When that occurs the parser fails to handle it.

If you can paste your raw output for a few runs, I can try updating the parser.

[jgrund]

And yeah, given we don't have useful output when formatting as JSON (and I needed Junit reporting), the current option was to parse the raw output.

Ultimately, having useful output in other formats would obviate this repo.

[devurandom]

I see the same:

thread 'main' panicked at 'Parser error', opt/cargo/registry/src/github.com-1ecc6299db9ec823/cargo-test-junit-0.6.1/src/main.rs:45
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:355
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:371
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:549
   5: std::panicking::begin_panic
   6: cargo_test_junit::main
   7: std::panicking::try::do_call
             at /checkout/src/libstd/panicking.rs:454
   8: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:98
   9: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:433
             at /checkout/src/libstd/panic.rs:361
             at /checkout/src/libstd/rt.rs:57
  10: __libc_start_main
  11: _start

How would I acquire the "raw test output"? Do you log that into some file?

[devurandom]

In case you mean the output of cargo test, this is what I see:

   Compiling libdrm-sys v0.2.0 (file://<<PROJECT>>)
warning: found non-foreign-function-safe member in struct marked #[repr(C)]: found struct without foreign-function-safe representation annotation in foreign module, consider adding a #[repr(C)] attribute to the type, #[warn(improper_ctypes)] on by default
    --> 
<<PROJECT>>/target/1.16.0/debug/build/libdrm-sys-99c34009add0f9d8/out/bindings.rs:5641:58
     |
5641 |     pub fn drmWaitVBlank(fd: ::std::os::raw::c_int, vbl: drmVBlankPtr)
     |                                                          ^^^^^^^^^^^^

Lots of these. They are a result of rust-lang/rust-bindgen#442, which has been fixed in Rust 1.17.0, but I do try to test my code with older versions, too.

[devurandom]

P.S. The list of tests seems to start at ^running (\d+) tests$ and it ends at ^test result: (\w+). (\d+) passed; (\d+) failed; (\d+) ignored; (\d+) measured$. Do you already use that to guide your parser?

[jgrund]

In case you mean the output of cargo test

@devurandom, yes. if you could paste the full stdout of cargo test (from a clean build), I can add a failing test case and address it.