[Apologies, I also asked this on c.l.p, but got no answer so far. I have not too much time left before I will be away for nearly 2 weeks] I wonder if this is a bug. I'm running a deamon thread doing some work in the background, and sometimes when Python exits I get tracebacks like this: Unhandled exception in thread: Traceback (most recent call last): File "c:\python21\lib\threading.py", line 393, in __bootstrap self.__stop() File "c:\python21\lib\threading.py", line 399, in __stop self.__block.notifyAll() File "c:\python21\lib\threading.py", line 235, in notifyAll self.notify(len(self.__waiters)) File "c:\python21\lib\threading.py", line 217, in notify me = currentThread() TypeError: object of type 'None' is not callable This traceback does not appear when I register an atexit function to stop the thread. Is this a bug? Aren't daemon threads supposed to clean up themselves? Thomas
[Apologies, I also asked this on c.l.p, but got no answer so far. I have not too much time left before I will be away for nearly 2 weeks]
I wonder if this is a bug. I'm running a deamon thread doing some work in the background, and sometimes when Python exits I get tracebacks like this:
Unhandled exception in thread: Traceback (most recent call last): File "c:\python21\lib\threading.py", line 393, in __bootstrap self.__stop() File "c:\python21\lib\threading.py", line 399, in __stop self.__block.notifyAll() File "c:\python21\lib\threading.py", line 235, in notifyAll self.notify(len(self.__waiters)) File "c:\python21\lib\threading.py", line 217, in notify me = currentThread() TypeError: object of type 'None' is not callable
This traceback does not appear when I register an atexit function to stop the thread.
Is this a bug? Aren't daemon threads supposed to clean up themselves?
This is probably a result of the destructive module finalization. When Py_Finalize() is called, threads that are still running are not killed. But Py_Finalize() replaces the values of all globals in modules with None (it could just clear the module's dictionary but there was some reason for doing it this way) and that is what you are probably seeing. If there was a primitive to kill a thread, we might use it in Py_Finalize() -- but there isn't (it's been requested but it's hard to see how to do it safely). --Guido van Rossum (home page: http://www.python.org/~guido/)
From: "Guido van Rossum" <guido@python.org>
[Apologies, I also asked this on c.l.p, but got no answer so far. I have not too much time left before I will be away for nearly 2 weeks]
I wonder if this is a bug. I'm running a deamon thread doing some work in the background, and sometimes when Python exits I get tracebacks like this:
Unhandled exception in thread: Traceback (most recent call last): File "c:\python21\lib\threading.py", line 393, in __bootstrap self.__stop() File "c:\python21\lib\threading.py", line 399, in __stop self.__block.notifyAll() File "c:\python21\lib\threading.py", line 235, in notifyAll self.notify(len(self.__waiters)) File "c:\python21\lib\threading.py", line 217, in notify me = currentThread() TypeError: object of type 'None' is not callable
This traceback does not appear when I register an atexit function to stop the thread.
Is this a bug? Aren't daemon threads supposed to clean up themselves?
This is probably a result of the destructive module finalization. When Py_Finalize() is called, threads that are still running are not killed. But Py_Finalize() replaces the values of all globals in modules with None (it could just clear the module's dictionary but there was some reason for doing it this way) and that is what you are probably seeing.
If there was a primitive to kill a thread, we might use it in Py_Finalize() -- but there isn't (it's been requested but it's hard to see how to do it safely).
But it seems the system is trying to stop the thread(s), maybe too late. In my case, atexit.register(self.stop) makes a clean shutdown. My point is: should the threading module do this? I can easily live with doing it myself - I just don't know if this is intended or required. Thomas
Unhandled exception in thread: Traceback (most recent call last): File "c:\python21\lib\threading.py", line 393, in __bootstrap self.__stop() File "c:\python21\lib\threading.py", line 399, in __stop self.__block.notifyAll() File "c:\python21\lib\threading.py", line 235, in notifyAll self.notify(len(self.__waiters)) File "c:\python21\lib\threading.py", line 217, in notify me = currentThread() TypeError: object of type 'None' is not callable
This traceback does not appear when I register an atexit function to stop the thread.
Is this a bug? Aren't daemon threads supposed to clean up themselves?
This is probably a result of the destructive module finalization. When Py_Finalize() is called, threads that are still running are not killed. But Py_Finalize() replaces the values of all globals in modules with None (it could just clear the module's dictionary but there was some reason for doing it this way) and that is what you are probably seeing.
If there was a primitive to kill a thread, we might use it in Py_Finalize() -- but there isn't (it's been requested but it's hard to see how to do it safely).
But it seems the system is trying to stop the thread(s), maybe too late. In my case, atexit.register(self.stop) makes a clean shutdown. My point is: should the threading module do this? I can easily live with doing it myself - I just don't know if this is intended or required.
Python doesn't attempt to stop daemon threads at all. Note that the __stop() call is in a finally clause. This probably gets hit because some other exception happened (caused by the same problem of globals being replaced by None). --Guido van Rossum (home page: http://www.python.org/~guido/)
[Thomas Heller]
Unhandled exception in thread: Traceback (most recent call last): File "c:\python21\lib\threading.py", line 393, in __bootstrap self.__stop() File "c:\python21\lib\threading.py", line 399, in __stop self.__block.notifyAll() File "c:\python21\lib\threading.py", line 235, in notifyAll self.notify(len(self.__waiters)) File "c:\python21\lib\threading.py", line 217, in notify me = currentThread() TypeError: object of type 'None' is not callable
This traceback does not appear when I register an atexit function to stop the thread.
We're missing basic info, like which OS and which Python release. More than one shutdown race has been fixed over the decades <wink>. I've seen reports of this before, but under older Pythons, and/or in conjunction with running GUIs where the problem went away if the GUI was taken out of the equation. AFAIK, nobody ever stuck with it long enough to track down the real cause, though. This relatively recent comment in pythonrun.c's Py_Finalize() is probably relevant: /* The interpreter is still entirely intact at this point, and the * exit funcs may be relying on that. In particular, if some thread * or exit func is still waiting to do an import, the import machinery * expects Py_IsInitialized() to return true. So don't say the * interpreter is uninitialized until after the exit funcs have run. * Note that Threading.py uses an exit func to do a join on all the * threads created thru it, so this also protects pending imports in * the threads created via Threading. */ call_sys_exitfunc(); initialized = 0; I expect that a *foreign* thread (== one not created by threading.py) isn't going to be waited for by threading.py's exit func .join(), and if so won't be protected by this mechanism (that's a shutdown race we can't really do anything about -- we've got no handle on what foreign threads do).
From: "Tim Peters" <tim.one@home.com>
[Thomas Heller]
Unhandled exception in thread: Traceback (most recent call last): File "c:\python21\lib\threading.py", line 393, in __bootstrap self.__stop() File "c:\python21\lib\threading.py", line 399, in __stop self.__block.notifyAll() File "c:\python21\lib\threading.py", line 235, in notifyAll self.notify(len(self.__waiters)) File "c:\python21\lib\threading.py", line 217, in notify me = currentThread() TypeError: object of type 'None' is not callable
This traceback does not appear when I register an atexit function to stop the thread.
We're missing basic info, like which OS and which Python release. More than one shutdown race has been fixed over the decades <wink>.
I've seen reports of this before, but under older Pythons, and/or in conjunction with running GUIs where the problem went away if the GUI was taken out of the equation. AFAIK, nobody ever stuck with it long enough to track down the real cause, though. Here's the short info (I can provide everything to produce this, but not today). ActiveState's Python 2.1.1, running under Win2k SP1. Haven't tried in other Python versions. No gui involved. The thread basically calls os.stat, not sure if it also calls reload().
Later, Thomas
[Thomas Heller]
Here's the short info (I can provide everything to produce this, but not today).
You overestimate my interest <wink>.
ActiveState's Python 2.1.1, running under Win2k SP1. Haven't tried in other Python versions. No gui involved. The thread basically calls os.stat, not sure if it also calls reload().
If you can produce a reasonably small failing program, that doesn't involve foreign threads (as before, we've got no handle on those), attach it to a new bug report on SourceForge. If I can reproduce it in core Python, I'll find a way to fix it; else it's unique to ActiveState's distro, and they'll have to tackle it.
If you can produce a reasonably small failing program, that doesn't involve foreign threads (as before, we've got no handle on those), attach it to a new bug report on SourceForge. If I can reproduce it in core Python, I'll find a way to fix it; else it's unique to ActiveState's distro, and they'll have to tackle it.
I think he mentioned it was a daemon thread, and those are not stopped -- they are let run just like foreign threads. I still believe in my theory which I posted earlier today. --Guido van Rossum (home page: http://www.python.org/~guido/)
[Guido]
I think he mentioned it was a daemon thread,
He wasn't clear about that.
and those are not stopped -- they are let run just like foreign threads.
I'm going to redefine what I mean by "foreign" then, to cover this too.
I still believe in my theory which I posted earlier today.
So do I.
participants (3)
-
Guido van Rossum -
Thomas Heller -
Tim Peters