[ python-Bugs-1061968 ] threads: segfault or Py_FatalError at exit

[SourceForge.net]

Bugs item #1061968, was opened at 2004-11-07 11:30
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061968&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 9
Submitted By: Armin Rigo (arigo)
>Assigned to: Armin Rigo (arigo)
Summary: threads: segfault or Py_FatalError at exit

Initial Comment:
I couldn't reproduce this bug on any machine but mine, but after investigation it looks like a real locking bug in pystate.c which triggers under a certain timing.  Attached is a small example which triggers the problem repeatedly on my machine, together with the output I get with a Python interpreter where I inserted debug prints in pystate.c:zapthreads() and pystate.c:PyThreadState_Delete().  My problem is that zapthreads() gets called before the last C thread finishes to call PyGILState_Release().  The very final call that PyGILState_Release() makes to PyThreadState_Delete() -- *after* it releases all locks -- then occurs after zapthreads() has cleared everything.  Crash.

Can't fix it myself because I don't know anything about PyGILState_*() and the intent of the various locks...

Boosted to priority 9 because it looks like it should be fixed before 2.4b3.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-11-07 17:26

Message:
Logged In: YES 
user_id=31435

Back to Armin -- would you please try the attached patch 
(gilrelease.txt)?  I've never been able to provoke this bug, so 
I can only verify that other tests don't break.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-11-07 14:48

Message:
Logged In: YES 
user_id=31435

Nasty, nasty, nasty.  This is a reappearance of this miserable 
old bug:

http://www.python.org/sf/225673

BTW, the comments there explain why I'm unlikely to see it 
on Windows.

That bug got fixed in rev 2.41 of threadmodule.c, by 
introducing the new PyThreadState_DeleteCurrent() function, 
which deletes the current tstate *while* holding the GIL.  
Guido should have inserted a large block of screaming 
comments at the same time, explaining how horridly subtle 
the need for that was.

3 years and 7 months later, Mark reintroduced the problem, in 
rev 2.59 of threadmodule.c.  That replaced the 
PyThreadState_DeleteCurrent() call by a call to  
PyGILState_Release(), and the latter-- like Python before rev 
2.41 --does *not* hold the GIL when it decides to delete the 
tstate.  That's the source of the timing hole you're falling into 
here.

Offhand I'm not sure what to do about it, because I'm not 
familiar with the other bug Mark was trying to fix with rev 
2.59.  I'm assigning to Mark under the hope that it will be 
instantly obvious to him.  Mark, if it's not, please assign it to 
me, and I'll try to work it all out.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061968&group_id=5470