[ python-Bugs-1041645 ] Thread management corrupts heap

SourceForge.net noreply at sourceforge.net
Wed Oct 6 20:15:39 CEST 2004


Bugs item #1041645, was opened at 2004-10-06 14:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1041645&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: benson margulies (benson_basis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread management corrupts heap

Initial Comment:
The PyGILState_Ensure mechanism appears to have a 
built-in heap-corrupting race condition.

If a new thread calls PyGILState_Ensure, then the code 
allocates a new 'tstate' for it on the heap. This 
allocation is not protected by any lock. So, multiple 
racing threads can hit the heap at the same time, and 
corrupt it.

I have observed this with both 2.3 and with 2.4a3.

I will attach a sample application. The application is 
Win32, but should be easy enough to adapt to Unix if 
someone cares to.

Since the stated purpose of this mechanism, in PEP311, 
is to allow any-old-thread to call into Python, I believe 
that the usage model here is legitimate.

To watch this explode, run the attached with arguments 
like, oh, 1 100 40 against the debug python build.




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

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


More information about the Python-bugs-list mailing list