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.

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.

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.

Logged In: YES 
user_id=14198

Damn - Tim beat me - I missed his comment and came up with
an almost identical patch.  I could not provoke the error on
my RH8 box, so can't offer any more assurance this fixes the
underlying bug

Logged In: YES 
user_id=31435

Thanks, Mark!  It's great to get another set of "been there, 
done that" eyeballs on thread nasties.  The symptoms look 
the same as the ones Guido reported 4 years ago, and there 
seems to be a clear reason for why they reappeared, so I'm 
optimistic that fixing it the same way again <wink> will work.

Logged In: YES 
user_id=31435

I may not be able to do anything here on Monday, so I 
checked in the patch, but will leave the report open until 
Armin can add more info:

Misc/NEWS 1.1186
Python/pystate.c 2.38

Logged In: YES 
user_id=4771

It looks fine and I can't reproduce the problem any more.  Thanks for the fix!

Logged In: YES 
user_id=357491

Any chance this can get backported to 2.3?

Logged In: YES 
user_id=14198

OK, I'll take it on for 2.3, but it might be worth reminding
me next you get the smell of a new 2.3 release.

Logged In: YES 
user_id=31435

I may be wrong, but I'm pretty sure Armin already backported 
all the thread fixes that went into 2.4 (including this one).

Logged In: YES 
user_id=4771

Yes, I double-checked again and I can confirm that the patch of pystate.c rev 2.38 was back-ported to 2.3.  Closing the bug report...

Logged In: YES 
user_id=190543

What's the current status of this bug? Did the bug fix make
it into 2.4.3?  When I run test13.py (attached to one of the
notes for this bug) with Python 2.4.3, it does not crash -
does that mean that the bug has been fixed?  If not, will it
be possible to have the fix included in 2.5?  

thanks
Stewart

Logged In: YES 
user_id=31435

midtoad:  This bug was closed in December of 2004.  The fix
was in 2.4 release candidate 1, also in late 2004.  It never
existed in 2.5.  Move along, folks, nothing to see here ;-)