While developing mysql-proxy I sometimes have to step-by-step refactoring that usually result in unstable code for a while until the unit-tests are happy again.
When a unit-test fails I usually use gdb as a wrapper and let it create a stack-trace for me:
$ gdb --command=backtrace.gdb --args /path/to/my/testcase
--command option is used to automate gdb:
run thread apply all bt quit
If the test finishes successfully, gdb will just quit, but on error we will get a nice, all-threads stack-trace.
In the end it looks like:
$ gdb --command=backtrace.gdb --args .../tests/unit/t_network_io ... Program received signal SIGINT, Interrupt. 0x909f43ae in __semwait_signal () Thread 2 (process 49948 thread 0x1003): #0 0x90a1d906 in kevent () #1 0x0006ee40 in kq_dispatch () #2 0x00062b26 in event_base_loop () #3 0x0000781a in mock_server (_udata=0x907dd0) at .../tests/unit/t_network_io.c:94 #4 0x0015198e in g_thread_create_proxy () #5 0x90a1e095 in _pthread_start () #6 0x90a1df52 in thread_start () Thread 1 (process 49948 local thread 0x2d03): #0 0x909f43ae in __semwait_signal () #1 0x90a39398 in pthread_join$UNIX2003 () #2 0x00041c51 in g_thread_join_posix_impl () #3 0x0015213a in g_thread_join () #4 0x00007f9d in t_network_io_start () at .../tests/unit/t_network_io.c:292 #5 0x0014eca5 in g_test_run_suite_internal () #6 0x0014eb80 in g_test_run_suite_internal () #7 0x0014eef8 in g_test_run_suite () #8 0x0014efa3 in g_test_run () #9 0x0000808e in main (argc=1, argv=0xbffff7b0) at .../tests/unit/t_network_io.c:306
BTW, yes I know that glib has a facility for this, but it doesn't use
thread apply all bt.