<br><br><div><span class="gmail_quote">On 5/1/07, <b class="gmail_sendername">Neal Norwitz</b> <<a href="mailto:nnorwitz@gmail.com">nnorwitz@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;">
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
</blockquote><div><br><br>The PyMem_MALLOC call that creates 'mode' is also called without explicitly holding the GIL.<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.</blockquote><div><br><br>I believe the GIL does not need to be held, but obviously Tim or someone with more memory experience should step in to say definitively.
<br><br>If you look at Include/pymem.h, PyMem_FREE gets defined as PyObject_FREE in a debug build. PyObject_Free is defined at _PyObject_DebugFree. That function checks that the memory has not been written with the debug bit pattern and then calls PyObject_Free. That call just sticks the memory back into pymalloc's memory pool which is implemented without using any Python objects.
<br><br>In other words no Python objects are used in pymalloc (to my knowledge) and thus is safe to use without the GIL.<br><br>-Brett<br></div></div>