'cargo test' got stuck (bug?)

help
1

I had 6 tests in my tests directory. However after 2 tests (both successful), the test driver seems stuck.

This is the stack trace that I can get using GDB. It shows cargo test is waiting for something. Anyone can give a clue?

[New Thread 0x171b of process 1270]
     Running target/debug/lib-81e41c15ad678ed0

running 6 tests
test test_ir::test_ir::test_factorial ... ok
test test_compiler::test_tree_gen::test_tree_gen ... ok
^C
Program received signal SIGINT, Interrupt.
0x00007fff8f64fe22 in __wait4 () from /usr/lib/system/libsystem_kernel.dylib
(gdb) info threads
  Id   Target Id         Frame
* 1    Thread 0x1503 of process 1270 0x00007fff8f64fe22 in __wait4 ()
   from /usr/lib/system/libsystem_kernel.dylib
(gdb) bt
#0  0x00007fff8f64fe22 in __wait4 ()
   from /usr/lib/system/libsystem_kernel.dylib
#1  0x000000010041e5d9 in process::_$LT$impl$GT$::wait::ha6f30f9c75e3d45c6Nm ()
#2  0x000000010041e3d3 in process::_$LT$impl$GT$::status::h896f5dc44becf1eeiBm
    ()
#3  0x000000010018af08 in util::process_builder::_$LT$impl$GT$::exec::he689fc0e90fed8988Ru ()
#4  0x00000001001b5542 in ops::cargo_rustc::engine::_$LT$impl$GT$::exec::h5df6ff7f0ff415cdndm ()
#5  0x000000010020665d in ops::cargo_test::run_unit_tests::h4c85706249f96b38Qgp
    ()
#6  0x00000001002019b9 in ops::cargo_test::run_tests::h6db4dd3553e5b3f8Hbp ()
#7  0x0000000100076167 in call_main_without_stdin::call_main_without_stdin::h10058708032144631429 ()
#8  0x000000010000c5af in execute::h8dd15dedd848b1e3Zca ()
#9  0x00000001000043f0 in call_main_without_stdin::call_main_without_stdin::h60977895025593982 ()
#10 0x0000000100001721 in main::h6438d455d6a15077Nca ()
#11 0x00000001004282d3 in sys_common::unwind::try::try_fn::h273701710550213095
    ()
#12 0x00000001004233e9 in __rust_try ()
#13 0x000000010042817a in rt::lang_start::h425220f787b1b804Uxx ()
#14 0x00000001000010b4 in start ()
(gdb)
2

I think I started to get a sense of the problem. On Mac, cargo test got stuck. However on Linux, it reported an stackover flow error in the 3rd test.

3

@qinsoon An easy way to start debugging test deadlocks is to set RUST_TEST_THREADS=1. When running single threaded the test running will print the test name before running the test, instead of after running the test. You can use this trick to see which test is hanging.

4 Likes
4

Thanks @brson. That would be a useful env var to use. It seems the testing thread meets a stack overflow in the test and quits, and the controller is waiting for a result that it will never get! This is the case on OSX; on Linux, everything is fine: either the stack overflow causes the whole process to quit or the controller notices the thread quit.

5

Hello @qinsoon, could you tell me how you got the stack trace using GDB. I seem to have the same problem.

Update

I found it, alright.

https://stackoverflow.com/a/27270506/2926992

6