Amaury Forgeot d'Arc added the comment:
Committed revision 59231 in trunk.
--
resolution: - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1402
__
Amaury Forgeot d'Arc added the comment:
The _PyGILState_Fini function might cause user code to run as well,
it removes the thread-local variable that contains the PyThreadState
for threads, and that contains some Python objects that might contain
arbitrary values (such as the last
Guido van Rossum added the comment:
No, _PyGILState_Fini does not invoke any python code
You're right. It calls PyThread_delete_key(). I thought this would
delete entries from a dictionary (thereby potentially invoking Python
code via Py_DECREF()), but it doesn't -- it just frees some memory.
Guido van Rossum added the comment:
So is this a Mac-only issue?
And couldn't the GIL state cleanup also invoke user code, which might be
abused to create more threads, wreaking havoc that way? I'm kind of
worried about putting this into 2.5.2 and breaking somebody's working
code (that's
Ronald Oussoren added the comment:
This is not a mac-specific issue, the script happens to be mac-specific
because that's how I found the issue.
Amaury's patch adds a unittest that reproduces the problem in a
platform-indepenent way using ctypes.
The _PyGILState_Fini function might cause
Amaury Forgeot d'Arc added the comment:
I managed to reproduce the problem consistently with the following code:
import ctypes, sys, time, thread
# Module globals are cleared before __del__ is run
# So save the functions in class dict
class C:
ensure = ctypes.pythonapi.PyGILState_Ensure
Ronald Oussoren added the comment:
The attached patch fixes the crash, but I haven't verified if the patch
is actually correct.
With this patch some PyThread API's are called after PyInterpreterState_Clear
and I don't know if it is valid to do so. All
unittests pass fine on OSX though.
Guido van Rossum added the comment:
Do you have a patch? Then we could consider fixing this in 2.5.2.
--
nosy: +gvanrossum
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1402
__
Ronald Oussoren added the comment:
I don't have a patch. I don't even know enough of the threading
infrastructure to know if this really a bug or if it is a bug in my
code.
I'll work on a patch this weekend, if changing the order of calls to
PyGILState_Fini and PyInterpreterState_Clear
New submission from Ronald Oussoren:
Py_Finalize cleans up the thread state by first calling _PyGILState_Fini
and then calling PyInterpreterState_Clear. The latter can cause user
code to run, which could use the GILState API and this then causes a
crash.
The attached file 'threads.py' causes
10 matches
Mail list logo
