This is the mail archive of the
gdb-testers@sourceware.org
mailing list for the GDB project.
[binutils-gdb] Python unwinder sniffer: PyExc_KeyboardInterrupt -> Quit
- From: sergiodj+buildbot at sergiodj dot net
- To: gdb-testers at sourceware dot org
- Date: Thu, 16 Nov 2017 19:19:18 -0500
- Subject: [binutils-gdb] Python unwinder sniffer: PyExc_KeyboardInterrupt -> Quit
- Authentication-results: sourceware.org; auth=none
*** TEST RESULTS FOR COMMIT 9ccabccd15603dbf9fe988c86708fe644d1398a7 ***
Author: Pedro Alves <palves@redhat.com>
Branch: master
Commit: 9ccabccd15603dbf9fe988c86708fe644d1398a7
Python unwinder sniffer: PyExc_KeyboardInterrupt -> Quit
If you happen to press Ctrl-C while GDB is running the Python unwinder
machinery, the Ctrl-C is swallowed by the Python unwinder machinery.
For example, with:
break foo
commands
> c
> end
and
while (1)
foo ();
and then let the inferior hit "foo" repeatedly, sometimes Ctrl-C
results in:
~~~
23 usleep (100);
Breakpoint 2, foo () at gdb.base/bp-cmds-continue-ctrl-c.c:23
23 usleep (100);
^C
Breakpoint 2, Python Exception <class 'KeyboardInterrupt'> <class 'KeyboardInterrupt'>:
foo () at gdb.base/bp-cmds-continue-ctrl-c.c:23
23 usleep (100);
Breakpoint 2, foo () at gdb.base/bp-cmds-continue-ctrl-c.c:23
23 usleep (100);
Breakpoint 2, foo () at gdb.base/bp-cmds-continue-ctrl-c.c:23
23 usleep (100);
~~~
Notice the Python exception above. The interesting thing here is that
GDB continues as if nothing happened, doesn't really stop and give
back control to the user. Instead, the Ctrl-C aborted the Python
unwinder sniffer and GDB moved on to just use another unwinder.
Fix this by translating a PyExc_KeyboardInterrupt back into a Quit
exception once back in GDB.
This was exposed by the new gdb.base/bp-cmds-continue-ctrl-c.exp
testcase added later in the series.
gdb/ChangeLog:
2017-11-16 Pedro Alves <palves@redhat.com>
* python/py-unwind.c (pyuw_sniffer): Translate
PyExc_KeyboardInterrupt to a GDB Quit exception.