Created on 2006-11-14 14:02 by cwalther, last changed 2012-07-09 21:15 by alexis.
|threadingbug.py||nobody, 2006-11-15 07:00||minimal reproducing example|
|thread_crash.py||amaury.forgeotdarc, 2008-01-17 20:04|
|msg30544 - (view)||Author: Christian Walther (cwalther)||Date: 2006-11-14 14:02|
Python 2.4.3 on Windows 2000, though the code in question seems unchanged in current SVN (r46919). I'm using Python embedded in a multithreaded C++ application. When 'import threading' is first done in some Python script that runs in thread A, I get the following exception when a different thread B calls Py_Finalize(): Error in atexit._run_exitfuncs: Traceback (most recent call last): File "C:\Python24\lib\atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "C:\Python24\lib\threading.py", line 636, in __exitfunc self._Thread__delete() File "C:\Python24\lib\threading.py", line 522, in __delete del _active[_get_ident()] KeyError: 680 Error in sys.exitfunc: Traceback (most recent call last): File "C:\Python24\lib\atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "C:\Python24\lib\threading.py", line 636, in __exitfunc self._Thread__delete() File "C:\Python24\lib\threading.py", line 522, in __delete del _active[_get_ident()] KeyError: 680 The reason seems to be that the threading module uses the thread ID of the calling thread as a key to store its _MainThread instance on initialization, and again the thread ID of the calling thread to delete it in its exit function. If these two threads are not the same, the described KeyError occurs. I didn't study this in all detail, but it seems to me that threading.Thread.__delete() does the wrong thing. By doing 'del _active[_get_ident()]', it removes the instance for the calling thread from the _active dictionary. What it should be doing is removing *self* from that dictionary. Is that correct?
|msg30545 - (view)||Author: Brett Cannon (brett.cannon) *||Date: 2006-11-14 21:59|
Well, I don't think you should be calling Py_Finalize() from the non-main thread. That just seems unsafe to me. Regardless, though, could you write up some quick Python code that triggers this?
|msg30546 - (view)||Author: Christian Walther (cwalther)||Date: 2006-11-15 07:02|
I'm not calling Py_Finalize from a non-main thread. What I called "thread B" is the main thread. It's the script that first imports the threading module that runs in a non-main thread (and running user-defined scripts in non-main threads is hopefully not unsafe, or there wouldn't be much point in supporting multithreading at all in Python). It didn't even occur to me that this could be reproduced in pure Python code, so I didn't include an example in my original post. Of course, it can - see attachment. Tested on Python 2.3.5 on Mac OS X.
|msg30547 - (view)||Author: Brett Cannon (brett.cannon) *||Date: 2006-11-15 18:51|
Thanks for the test code. I have no clue when I or anyone else will get to this, but the report and testing code is appreciated.
|msg60013 - (view)||Author: Gregory P. Smith (gregory.p.smith) *||Date: 2008-01-17 01:47|
threadingbug.py doesn't fail for me on trunk (linux), anyone else? the output I get is always: Main thread ID: -134346528 Secondary thread ID: -135349328 Exception KeyError: KeyError(-134346528,) in <module 'threading' from '/home/gps/oss/python/trunk/Lib/threading.pyc'> ignored
|msg60035 - (view)||Author: Christian Walther (cwalther)||Date: 2008-01-17 17:13|
I'm not sure what you mean by "doesn't fail" - from the output you quote, I'd say that it does fail. It's in fact the same output as I get right now with Python 2.5.1 on Mac OS X. Would you classify that KeyError as expected behavior?
|msg60041 - (view)||Author: Gregory P. Smith (gregory.p.smith) *||Date: 2008-01-17 18:14|
gah, sorry i misread the report. you are correct.
|msg60050 - (view)||Author: Adam Olsen (Rhamphoryncus)||Date: 2008-01-17 18:54|
Is the bug avoided if you import threading first and use it instead of thread? I'd like to see thread removed in 3.0 (renamed to _thread or the like.)
|msg60052 - (view)||Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) *||Date: 2008-01-17 20:04|
If a python daemon thread is still running when the interpreter exits, it is likely to fail in random ways. Here is another example, which does not use imports. I run the script many times, with latest version in trunk, on Windows XP, debug build. In the majority of runs, I get an error message: """ Exception in thread Thread-1 (most likely raised during interpreter shutdown): """ Other tests seem to show that all modules are emptied by the cleanup process, but the thread insists to get "time.sleep". And more interestingly, about every 50 runs, the process segfaults... I suspect that this is a problem similar to http://bugs.python.org/issue1856
|msg60083 - (view)||Author: Christian Walther (cwalther)||Date: 2008-01-18 08:54|
> Is the bug avoided if you import threading first and use it instead of thread? Yes. The bug happens when the (first) import of threading and the call to Py_Finalize() happen in different threads. To reproduce the problem in pure Python, I therefore have to use thread instead of threading to create the secondary thread. (In the C++ application, it's created on the C++ side.) Has anyone checked if the solution I propose in the first post makes sense?
|msg97989 - (view)||Author: Brian Curtin (brian.curtin) *||Date: 2010-01-18 04:44|
FWIW, Amaury's example runs without error on trunk and py3k (OS X 10.5). 2.6 prints the following: "Exception in thread Thread-1 (most likely raised during interpreter shutdown)" 3.1 seg faults
|msg98031 - (view)||Author: Christian Walther (cwalther)||Date: 2010-01-18 20:40|
I have the impression we're tracking two completely unrelated problems in this tracker item. As to "needs patch" regarding my problem: Here's the solution I proposed in my original post in patch form - I'm just not sure if it is correct. I don't recommend applying this until someone who is familiar with the workings of the threading module has confirmed that removing self from _active is the right thing to do (and that what I'm doing is the accepted pythonic way of removing a dictionary entry by value). Index: Lib/threading.py =================================================================== --- Lib/threading.py (revision 77598) +++ Lib/threading.py (working copy) @@ -611,7 +611,11 @@ try: with _active_limbo_lock: - del _active[_get_ident()] + for k, v in _active.iteritems(): + if v is self: break + else: + assert False, "thread instance not found in _active" + del _active[k] # There must not be any python code between the previous line # and after the lock is released. Otherwise a tracing function # could try to acquire the lock again in the same thread, (in
|msg101890 - (view)||Author: Antoine Pitrou (pitrou) *||Date: 2010-03-29 14:50|
I think the fix to Christian's issue is just: Index: Lib/threading.py =================================================================== --- Lib/threading.py (révision 79470) +++ Lib/threading.py (copie de travail) @@ -579,7 +579,7 @@ try: # We don't call self.__delete() because it also # grabs _active_limbo_lock. - del _active[_get_ident()] + del _active[self.__ident] except: pass @@ -615,7 +615,7 @@ try: with _active_limbo_lock: - del _active[_get_ident()] + del _active[self.__ident] # There must not be any python code between the previous line # and after the lock is released. Otherwise a tracing function # could try to acquire the lock again in the same thread, (in Now we just need to add a test for it in test_threading. And, yes, Amaury's test case looks like a different issue.
|msg107903 - (view)||Author: Craig McQueen (cmcqueen1975)||Date: 2010-06-16 02:54|
From my limited experience using cx_Freeze 4.1.2 with Python 2.6.5, it seems that this issue is triggered in a cx_Frozen program simply by having `import threading` in the program. I'm not sure what cx_Freeze is doing that makes this issue show up.
|msg107904 - (view)||Author: Craig McQueen (cmcqueen1975)||Date: 2010-06-16 02:57|
Sorry I should have said, I'm running on Windows 2000 SP4.
|msg109088 - (view)||Author: Craig McQueen (cmcqueen1975)||Date: 2010-07-02 02:59|
A follow-on re the cx_Freeze issue: I looked at the source code, and found it doesn't seem to be doing any thread creation. But I found that in the initscripts/Console.py, there are the following lines: if sys.version_info[:2] >= (2, 5): module = sys.modules.get("threading") if module is not None: module._shutdown() If these lines are commented-out, then the error message at exit does not occur.
|msg110202 - (view)||Author: Laurent Mazuel (Laurent.Mazuel)||Date: 2010-07-13 15:02|
Another solution for cx-freeze problem: http://code.google.com/p/modwsgi/issues/detail?id=197#c5 Which can be added in ConsoleKeepPath.c for instance
|msg133043 - (view)||Author: (hasenpfeffer)||Date: 2011-04-05 15:28|
I encountered this issue recently in Python 3.2 and wanted to make some observations about it. The real problem here is not the KeyError. Though the suggested patches would fix the KeyError symptom, they do not fix the underlying issue. The underlying issue is the threading module assumes that it is imported from the Python main thread. When alien threads exist, the threading module may be imported (directly or indirectly) from a thread that is not the Python main thread, causing the wrong thread to be marked as the Python main thread. The resulting problems of the wrong thread being marked as the Python main thread appear to be minor. The KeyError at exit is one of them. Another problem I encountered was with confusion in a threaded debugger that displayed my alien thread as the Python main thread, and the Python main thread as the alien thread. In my project I can easily work around this by importing the threading module in a root package that is extremely likely to be imported from the Python main thread, causing the correct thread to be marked as the main thread. Since I have a workaround for my project, in addition to the relatively minor issues that result from this behavior, I haven't spent any time looking into how to fix the underlying issue. If I have the time, I'll suggest one.
messages: + msg133043
versions: + Python 2.7, Python 3.2, - Python 2.6, Python 3.1
messages: + msg110202
|2010-07-02 02:59:09||cmcqueen1975||set||messages: + msg109088|
|2010-06-16 02:57:41||cmcqueen1975||set||messages: + msg107904|
messages: + msg107903
messages: + msg101890
|2010-01-18 20:40:08||cwalther||set||messages: + msg98031|
+ Python 3.1, - Python 2.5, Python 2.4|
nosy: + brian.curtin
messages: + msg97989
stage: needs patch
|2009-02-17 17:20:49||amaury.forgeotdarc||link||issue1159425 superseder|
|2008-01-18 08:55:01||cwalther||set||messages: + msg60083|
nosy: + amaury.forgeotdarc
messages: + msg60052
messages: + msg60050
versions: + Python 2.6, Python 2.5, Python 2.4
|2008-01-17 17:13:26||cwalther||set||messages: + msg60035|
messages: + msg60013