<br><br><div><span class="gmail_quote">On 5/1/07, <b class="gmail_sendername">Tim Peters</b> <<a href="mailto:tim.peters@gmail.com">tim.peters@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
[Neal Norwitz]<br>>> In rev 54982 (the first time this crash was seen), I see something<br>>> which might create a problem. In python/trunk/Modules/posixmodule.c<br>>> (near line 6300):<br>>><br>>> + PyMem_FREE(mode);
<br>>> Py_END_ALLOW_THREADS<br><br>Shouldn't do that.<br><br>[Brett Cannon]<br>> The PyMem_MALLOC call that creates 'mode' is also called without explicitly<br>> holding the GIL.<br><br>Or that ;-)
</blockquote><div><br><br>Luckily I misread the code so it doesn't do that boo-boo.<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
>> Can you call PyMem_FREE() without the GIL held? I couldn't find it<br>>> documented either way.<br><br>> I believe the GIL does not need to be held, but obviously Tim or someone<br>> with more memory experience should step in to say definitively.
<br><br>The GIL should be held. The relevant docs are in the Python/C API<br>manual, section "8.1 Thread State and the Global Interpreter Lock":<br><br> Therefore, the rule exists that only the thread that has acquired the global
<br> interpreter lock may operate on Python objects or call Python/C<br>API functions.<br><br>PyMem_XYZ is certainly a "Python/C API function". There are functions<br>you can call without holding the GIL, and section
8.1 intends to give<br>an exhaustive list of those. These are functions that can't rely on<br>the GIL, like PyEval_InitThreads() (which /creates/ the GIL), and<br>various functions that create and destroy thread and interpreter
<br>state.<br><br>> If you look at Include/pymem.h, PyMem_FREE gets defined as PyObject_FREE in<br>> a debug build. PyObject_Free is defined at _PyObject_DebugFree. That<br>> function checks that the memory has not been written with the debug bit
<br>> pattern and then calls PyObject_Free. That call just sticks the memory back<br>> into pymalloc's memory pool which is implemented without using any Python<br>> objects.<br><br>But pymalloc's pools have a complex internal structure of their own,
<br>and cannot be mucked with safely by multiple threads simultaneously.</blockquote><div><br><br>Ah, OK. That makes sense. Glad I pointed out my ignorance then. =)<br></div></div><br>-Brett