Kristján Valur Jónsson <krist...@ccpgames.com> added the comment: Ok, this means that the exception is raised after the finally, when the thread is exiting. Now, at this point the process is exiting and therefore we have trouble printing the exception. (this is probably also the cause of the exception in the first place, some cleanup that fails because the process is exiting). Now, the traceback printing code is complex and it could fail in a multitude of places, but from the stuff that is output, it would appear that printing to sys.stderr is failing. To find out the error, we need to goad python into displaying the exception, even though the process is exiting. On a windows machiine, I would put a DebugBreak() call in t_bootstrap() in threadmodule_t and try to find out where the error output code is failing. I don't know if you can do just-in-time debugging on your machine. It would be best, of course, to singlestep through the code at line 452 in threadmodule.c. Then we could pinpoint where the output is failing and fix python to make it more resilient at process exit.
Now, lines 452-455 don't produce any output. For starters, try to insert "file=0" before line 452 in threadmodule.c, so that PyObject_Print is called instead of PyFile_WriteObject() (which I think is failing.) If that produces output, then we can proceed to hardwire "stderr" into the traceback stuff. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6499> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
