<br><br><div><span class="gmail_quote">On 5/1/07, <b class="gmail_sendername">Neal Norwitz</b> &lt;<a href="mailto:nnorwitz@gmail.com">nnorwitz@gmail.com</a>&gt; 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.&nbsp;&nbsp;In python/trunk/Modules/posixmodule.c<br>(near line 6300):<br><br>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PyMem_FREE(mode);<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Py_END_ALLOW_THREADS
</blockquote><div><br><br>The PyMem_MALLOC call that creates &#39;mode&#39; is also called without explicitly holding the GIL.<br>&nbsp;</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?&nbsp;&nbsp;I couldn&#39;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.&nbsp; PyObject_Free is defined at _PyObject_DebugFree.&nbsp; That function checks that the memory has not been written with the debug bit pattern and then calls PyObject_Free.&nbsp; That call just sticks the memory back into pymalloc&#39;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>