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?

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?

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.

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.

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

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?

gah, sorry i misread the report.  you are correct.

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.)

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

> 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?

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

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

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.

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.

Sorry I should have said, I'm running on Windows 2000 SP4.

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.

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

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.

Only few people seem to use daemon threads. We do and see this problem often with Python 2.7.

How difficult is it to get this fixed for 2.7?

Is there a way to work around this problem?

related: issue #39042 "Use the runtime's main thread ID in the threading module."

The output is different now. 

I update the script for python 3:

---------------------------------------------
import _thread as thread
import time

def start():
	print("Secondary thread ID:", thread.get_ident())
	import threading

print("Main thread ID:", thread.get_ident())
thread.start_new_thread(start, ())
time.sleep(1)

---------------------------------------------

and the output is:

---------------------------------------------

Main thread ID: 4432801280
Secondary thread ID: 123145384259584
Exception ignored in: <module 'threading' from '/Users/iritkatriel/src/cpython-perf/Lib/threading.py'>
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython-perf/Lib/threading.py", line 1512, in _shutdown
    assert tlock.locked()
    ^^^^^^^^^^^^^^^^^^^^^
AssertionError: 

---------------------------------------------

I proposed PR 28549 to fix this very old threading issue.

A C extension can spawn threads without using the threading module and then then run Python code which imports the threading module. In this case, threading._main_thread is the thread which imported first the threading module. My PR changes so threading._shutdown() simply ignores _main_thread when it happens.

New changeset 95d31370829b7d729667588e0a9943217401ea5b by Victor Stinner in branch 'main':
bpo-1596321: Fix threading._shutdown() for the main thread (GH-28549)
https://github.com/python/cpython/commit/95d31370829b7d729667588e0a9943217401ea5b

New changeset 38c67738c64304928c68d5c2bd78bbb01d979b94 by Miss Islington (bot) in branch '3.10':
bpo-1596321: Fix threading._shutdown() for the main thread (GH-28549)
https://github.com/python/cpython/commit/38c67738c64304928c68d5c2bd78bbb01d979b94

New changeset 94d19f606fa18a1c4d2faca1caf2f470a8ce6d46 by Victor Stinner in branch '3.9':
bpo-1596321: Fix threading._shutdown() for the main thread (GH-28549) (GH-28589)
https://github.com/python/cpython/commit/94d19f606fa18a1c4d2faca1caf2f470a8ce6d46

Better late than never. I only took 15 years to fix this old bug :-D