[issue1596321] KeyError at exit after 'import threading' in other thread

[Gregory P. Smith]

Gregory P. Smith added the comment:

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  ignored

--
nosy: +gregory.p.smith

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1596321] KeyError at exit after 'import threading' in other thread

[Christian Walther]

Christian Walther added the comment:

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?

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1596321] KeyError at exit after 'import threading' in other thread

[Gregory P. Smith]

Gregory P. Smith added the comment:

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

--
versions: +Python 2.4, Python 2.5, Python 2.6

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1596321] KeyError at exit after 'import threading' in other thread

[Adam Olsen]

Adam Olsen added the comment:

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

--
nosy: +Rhamphoryncus

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1596321] KeyError at exit after 'import threading' in other thread

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

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

--
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file9195/thread_crash.py

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1596321] KeyError at exit after 'import threading' in other thread

[Christian Walther]

Christian Walther added the comment:

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

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1596321] KeyError at exit after 'import threading' in other thread

[Torsten Bronger]

Changes by Torsten Bronger :


--
nosy: +bronger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1596321] KeyError at exit after 'import threading' in other thread

[Antoine Pitrou]

Antoine Pitrou  added the comment:

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.

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1596321] KeyError at exit after 'import threading' in other thread

[Craig McQueen]

Craig McQueen  added the comment:

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

--
nosy: +cmcqueen1975

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1596321] KeyError at exit after 'import threading' in other thread

[Craig McQueen]

Craig McQueen  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1596321] KeyError at exit after 'import threading' in other thread

[Craig McQueen]

Craig McQueen  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1596321] KeyError at exit after 'import threading' in other thread

[Laurent Mazuel]

Laurent Mazuel  added the comment:

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

--
nosy: +Laurent.Mazuel

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1596321] KeyError at exit after 'import threading' in other thread

[hasenpfeffer]

hasenpfeffer  added the comment:

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.

--
nosy: +hasenpfeffer
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1596321] KeyError at exit after 'import threading' in other thread

[Alexis Metaireau]

Changes by Alexis Metaireau :


--
nosy: +alexis

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1596321] KeyError at exit after 'import threading' in other thread

[Brian Curtin]

Brian Curtin  added the comment:

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

--
nosy: +brian.curtin
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.1 -Python 2.4, Python 2.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1596321] KeyError at exit after 'import threading' in other thread

[Christian Walther]

Christian Walther  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com