aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.dap/max-size.c
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2025-04-22 23:01:58 +0100
committerAndrew Burgess <aburgess@redhat.com>2025-04-23 23:54:02 +0100
commit8e2ae00bb4d92e385f78d9a2be192de46d21b242 (patch)
tree0815310c8b5a94d144737ed043ddcae37a6bbb39 /gdb/testsuite/gdb.dap/max-size.c
parent1fc2d1491c0d512c61303f71d2ba420dd389da0f (diff)
downloadgdb-master.zip
gdb-master.tar.gz
gdb-master.tar.bz2
gdb/python: don't use PyObject_IsInstance in py-unwind.cHEADmaster
I've been reviewing all uses of PyObject_IsInstance, and I believe that the use of PyObject_IsInstance in py-unwind.c is not entirely correct. The use of PyObject_IsInstance is in this code in frame_unwind_python::sniff: if (PyObject_IsInstance (pyo_unwind_info, (PyObject *) &unwind_info_object_type) <= 0) error (_("A Unwinder should return gdb.UnwindInfo instance.")); The problem is that PyObject_IsInstance can return -1 to indicate an error, in which case a Python error will have been set. Now, the above code appears to handle this case, it checks for '<= 0', however, frame_unwind_python::sniff has this near the start: gdbpy_enter enter_py (gdbarch); And looking in python.c at 'gdbpy_enter::~gdbpy_enter ()', you'll notice that if an error is set then the error is printed, but also, we get a warning about an unhandled Python exception. Clearly, all exceptions should have been handled by the time the gdbpy_enter destructor is called. I've added a test as part of this commit that exposes this problem, the current output is: (gdb) backtrace Python Exception <class 'RuntimeError'>: error in Blah.__class__ warning: internal error: Unhandled Python exception Python Exception <class 'gdb.error'>: A Unwinder should return gdb.UnwindInfo instance. #0 corrupt_frame_inner () at /home/andrew/projects/binutils-gdb/build.dev-g/gdb/testsuite/../../../src.dev-g/gdb/test> (gdb) An additional observation is that we use PyObject_IsInstance to check that the return value is a gdb.UnwindInfo, or a sub-class. However, gdb.UnwindInfo lacks the Py_TPFLAGS_BASETYPE flag, and so cannot be sub-classed. As such, PyObject_IsInstance is not really needed, we could use PyObject_TypeCheck instead. The PyObject_TypeCheck function only returns 0 or 1, there is no -1 error case. Switching to PyObject_TypeCheck then, fixes the above problem. There's a new test that exposes the problems that originally existed. Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'gdb/testsuite/gdb.dap/max-size.c')
0 files changed, 0 insertions, 0 deletions