When you use gdb.execute() it automatically translates any exception to RuntimeError. At least for gdb.GdbError it should not do this, as its purpose is to display a message to the user and not show them a big fat traceback. In fact, I'm not sure gdb.execute() should translate exceptions at all for errors originating in Python code. (gdb) python >class C(gdb.Command): > def invoke(self, *args): > raise gdb.GdbError("This is a nonexistent command!") >C("some-command", gdb.COMMAND_NONE) >end (gdb) some-command This is a nonexistent command! (gdb) python gdb.execute("some-command") Traceback (most recent call last): File "<string>", line 1, in <module> RuntimeError: This is a nonexistent command! Error while executing Python code. (gdb)
It actually took me a few hours of hacking to figure this out. It's not really a bug in that you will never have anything that faces Python (ie can be called from a Python script) that will just print a message and no stack trace. gdb.GdbError gets converted to a GDB exception which has its own handling mechanism within GDB. When a GDB exception ends up at the border between the Python API and GDB it gets converted into a Python exception. Python has no idea how to deal with a GDB exception. So in this case it went from a gdb.GdbError to a GDB Exception back to a GdbError exception. This is usless, but harmless. This is the case with gdb.execute, gdb.parse_and_eval and a few other functions. As far as I know, there is no Python C API to deal specifically or alter how Python prints backtraces from exceptions. We seem to be able to either print it or not. I'll leave this open for a few days in case you disagree, or know of some other way to fix the bug. After that will close it.
Created attachment 5321 [details] Preserve Python exception information through GDB code
(In reply to comment #2) > Created attachment 5321 [details] > Preserve Python exception information through GDB code It seems sourceware forgot about my actual comment, so here goes. For GDB commands, the C function that is invoking the Python 'invoke' method of Command subclasses is clearing the exception, decreffing the type, value and traceback, and is then calling error() with the message string of the Python exception. At this point all Python information except for the exception message (in case this was actually a string!) is lost. So instead I propose to leave the Python error indicator installed, and have py-utils.c:gdbpy_convert_exception() check if a Python error indicator is set. If so, it can simply re-raise (i.e., propagate) it. I attached an untested patch, because unfortunately I don't have archer compiled at this moment.