PyHANDLE destructor triggers a SystemError

[ghost]

This code is in PyHANDLE.cpp:

/*static*/ void PyHANDLE::deallocFunc(PyObject *ob)
{
// Call virtual method Close
((PyHANDLE *)ob)->Close();
PyErr_Clear(); // can not leave pending exceptions
in destructors.
delete (PyHANDLE *)ob;
}

If this is called because an unrelated exception
occurred, it incorrectly clears the exception.

For example, suppose I have Python code that calls a
Python function f1(). This function successfully
creates a PyHANDLE, stores it in a local varaible, and
then raises an unrelated exception. The caller, f2(),
catches the exception. At this point, the PyHANDLE
still exists because the traceback object has a
reference to it (indirectly). Now suppose f2() throws
an exception. The previous traceback object is now
released (replaced by the new traceback). The PyHANDLE
object is decref'd and freed. PyHANDLE::deallocFunc()
is called. The exception that f2() threw is now cleared.

This results in a SystemError. The attached test case
reproduces it.

I think it should be

if (!((PyHANDLE *)ob)->Close())
PyErr_Clear();

but I'm not sure.

Reported by: jorend

Original Ticket: "pywin32/bugs/9":https://sourceforge.net/p/pywin32/bugs/9

[ghost]

Test case.

Original comment by: jorend

[ghost]

• assigned_to: nobody --> mhammond

Original comment by: jorend

[ghost]

Logged In: YES
user_id=14198

This is a little nasty. I think the PyErr_Clear call is a
hack, but Python prints a warning in some cases. The
semantics for exceptions during object destruction are hard,
and I will need to look into things a little more - but in
the meantime, please see the new win32\tests\handles.py -
your test case with some additions. These additions
exercise some of these other cases, which will hopefully
allow you to see my dilemma.

I've been meaning to move to unittest, and this gave me the
push I needed - thanks! I will probably move some of the
other "demos" code into tests where it belongs.

Original comment by: mhammond

[ghost]

• status: open --> closed-fixed

Original comment by: mhammond

[ghost]

Logged In: YES
user_id=14198

This has been fixed for a while now, and should be in the
most recent build. win32\test\handles.py should demonstrate
it is fixed.

Original comment by: mhammond