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