This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author amaury.forgeotdarc
Recipients amaury.forgeotdarc, gregory.p.smith, gvanrossum
Date 2008-01-17.20:44:13
SpamBayes Score 0.00179781
Marked as misclassified No
Message-id <>
I uploaded a script for a similar issue: (
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: 
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.
Date User Action Args
2008-01-17 20:44:19amaury.forgeotdarcsetspambayes_score: 0.00179781 -> 0.00179781
recipients: + amaury.forgeotdarc, gvanrossum, gregory.p.smith
2008-01-17 20:44:19amaury.forgeotdarcsetspambayes_score: 0.00179781 -> 0.00179781
messageid: <>
2008-01-17 20:44:14amaury.forgeotdarclinkissue1856 messages
2008-01-17 20:44:13amaury.forgeotdarccreate