Amaury Forgeot d'Arc added the comment:
I uploaded a script for a similar issue:
http://bugs.python.org/issue1596321 (thread_crash.py)
which sometimes segfaults on Windows XP (trunk version, debug build),
with the same call stacks as printed by Gregory, on both threads.
I explain it this way:
On interpreter shutdown, the main thread clears the other's thread
TreadState. There you find the instruction:
Py_CLEAR(tstate->frame);
But this can call arbitrary python code on deallocation of locals, and
release the GIL (file.close() in our case).
The other thread can then continue to run. If it is given enough
processor time before the whole process shutdowns, it will reach this
line in ceval.c (line 2633)
if (tstate->frame->f_exc_type != NULL)
since tstate->frame has been cleared by the main thread ==> boom.
There can be several ways to solve this problem:
- While clearing a thread state, prevent the "owner" thread to gain
focus. Only the main thread can "Py_END_ALLOW_THREADS". The daemon
thread is blocked forever, and will die there.
- Be smarter when clearing tstate->frame: first call frame_clear(),
which will free local variables, but let the frame in a valid state.
Only after that, call Py_CLEAR(tstate->frame), when we are sure that no
more thread switch can occur. Of course there are many other fields in a
frame; we have to inspect them carefully. The first solution seems a
more robust approach.
----------
nosy: +amaury.forgeotdarc
__________________________________
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1856>
__________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
