Title: PyErr_PrintEx exits silently when passed SystemExit exception
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 3.4, Python 3.5, Python 2.7
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: Marc.Horowitz, iritkatriel, vstinner
Priority: normal Keywords:

Created on 2010-11-29 18:46 by Marc.Horowitz, last changed 2021-06-17 11:25 by iritkatriel. This issue is now closed.

File name Uploaded Description Edit Marc.Horowitz, 2010-11-29 18:46 simple script to reproduce
Messages (3)
msg122846 - (view) Author: Marc Horowitz (Marc.Horowitz) Date: 2010-11-29 18:46
I discovered this bug working with panda3d.  I've attached a short
python script which demonstrates the problem.  After installing
panda3d, run the script, and then hit q in the window which appears.
You'll see that none of the cleanup code after the 'run()' main loop

The underlying cause is in how panda3d uses the C API.  It's got code
like this (in src/pipeline/thread.cxx):

    // Call the user's function.
    result = PyObject_Call(function, args, NULL);
    if (result == (PyObject *)NULL && PyErr_Occurred()) {
      // We got an exception.  Move the exception from the current
      // thread into the main thread, so it can be handled there.
      PyObject *exc, *val, *tb;
      PyErr_Fetch(&exc, &val, &tb);

        << "Exception occurred within " << *this << "\n";

      // Temporarily restore the exception state so we can print a
      // callback on-the-spot.
      PyErr_Restore(exc, val, tb);


If the code being called (generally a panda3d task function or event
handler) calls sys.exit, the PyErr_Print() never returns.  This is
surprising, as the the documentation never mentions that a function
with an innocuous name like "Print" might never return.  

However, I don't think this is a panda3d bug; I think that the
function as documented is the way it should behave.  Otherwise, the
vast majority of calls to this method will need to look like

    if (!PyErr_ExceptionMatches(PyExc_SystemExit)) {

which seems like a poor abstraction.

Another unexpected side effect is when python is used with the -i
flag.  Because of the way this alters the normal exit behavior, the
code runs the way I'd expect, and the cleanup code in the test
application *does* run.  It seems rather strange to me that cleanup
code should run or not run based on the -i flag.

I believe the fix for all this is that PyErr_PrintEx be changed to
behave as documented, *not* call handle_system_exit() when passed
SystemExit, and instead in the places where the interpreter main loop
is run, followed by PyErr_PrintEx(), that SystemExit is special cased
in those specific locations as needed.
msg220824 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-06-17 13:08
@Marc please accept our apologies for having missed this. Can you still reproduce the problem?
msg395996 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2021-06-17 11:25
This was removed in
Date User Action Args
2021-06-17 11:25:21iritkatrielsetstatus: open -> closed

nosy: + iritkatriel
messages: + msg395996

resolution: out of date
stage: resolved
2019-03-15 23:22:07BreamoreBoysetnosy: - BreamoreBoy
2014-06-17 13:27:44vstinnersetnosy: + vstinner
2014-06-17 13:08:13BreamoreBoysetnosy: + BreamoreBoy

messages: + msg220824
versions: + Python 2.7, Python 3.4, Python 3.5, - Python 2.6
2010-11-29 18:46:30Marc.Horowitzcreate