]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
Python unwinder sniffer: PyExc_KeyboardInterrupt -> Quit
authorPedro Alves <palves@redhat.com>
Thu, 16 Nov 2017 18:44:44 +0000 (18:44 +0000)
committerPedro Alves <palves@redhat.com>
Thu, 16 Nov 2017 18:44:44 +0000 (18:44 +0000)
commit9ccabccd15603dbf9fe988c86708fe644d1398a7
tree2d3e5744f9061b1ada553d7f0ae832958ac07f4e
parentd930703d68ae160ddfe8ebe5fdcf416fb6090e1e
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.
gdb/ChangeLog
gdb/python/py-unwind.c