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

The --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.


Comments

Enable javascript to load comments.