Capture backtrace at abort with gdb

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Capture backtrace at abort with gdb

Tom de Vries

I ran into a gdb abort in test-case gdb.base/bp-cmds-continue-ctrl-c.exp.

I decided to use gdb itself to try and capture the backtrace at the
point of abort.

I tried moving gdb to gdb.exec and adding a script gdb with:


exec $gdb -batch -ex r -ex bt -ex q --args $gdb "$@"

This didn't work.  There's a difference how gdb handles ^C
normally, in which case just "Quit" is printed:
$ /usr/bin/gdb -q
(gdb) Quit
and when gdb is run as inferior of gdb:
$ /usr/bin/gdb -q -batch -ex r --args /usr/bin/gdb -q
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/".
[Detaching after vfork from child process 24707]
Program received signal SIGINT, Interrupt.
0x00007ffff58ae6a4 in __GI___poll (fds=0x5555564d03a0, nfds=4,
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29        return SYSCALL_CANCEL (poll, fds, nfds, timeout);

I managed to make this work in the end by adding this as first command:
-ex "handle SIGINT nostop print pass"

[ FWIW, the abort was the PyOS_InterruptOccurred problem for python 3.8,
fixed by commit c47bae859a "Fix Python3.9 related runtime problems". ]

I wonder:
- should we have a comment about this in testsuite/README
- should we facilitate this in some way, by having a contrib script or
  a command line switch
- should we use this mechanism in the gdb testsuite
- should we make gdb abort in a more intelligent fashion

- Tom