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.0017978128 |
| Marked as misclassified | No |
| Message-id | <1200602659.39.0.80643492676.issue1856@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
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. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年01月17日 20:44:19 | amaury.forgeotdarc | set | spambayes_score: 0.00179781 -> 0.0017978128 recipients: + amaury.forgeotdarc, gvanrossum, gregory.p.smith |
| 2008年01月17日 20:44:19 | amaury.forgeotdarc | set | spambayes_score: 0.00179781 -> 0.00179781 messageid: <1200602659.39.0.80643492676.issue1856@psf.upfronthosting.co.za> |
| 2008年01月17日 20:44:14 | amaury.forgeotdarc | link | issue1856 messages |
| 2008年01月17日 20:44:13 | amaury.forgeotdarc | create | |