Files
binutils-gdb/gdb/python
Andrew Burgess 8e2ae00bb4 gdb/python: don't use PyObject_IsInstance in py-unwind.c
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>
2025-04-23 23:54:02 +01:00
..
2025-04-08 10:54:39 -06:00
2025-04-17 09:25:55 -06:00
2024-04-02 11:21:39 -06:00