homepage

My Apache2 logs are filled with the following error kicked out by my python wsgi script:
[Wed Mar 14 18:16:38 2012] [error] Exception AttributeError: AttributeError("'_DummyThread' object has no attribute '_Thread__block'",) in <module 'threading' from '/usr/lib/python2.7/threading.pyc'> ignored
I was able to silence these with a simple conditional in /usr/lib/python2.7/threading.pyc:
- del self._Thread__block
+ if hasattr(self, '_Thread__block'):
+ del self._Thread__block
Full patch attached.

I don't understand how that can happen, since _Thread__block is initialized in Thread.__init__, which is called by _DummyThread.__init__. Did you somehow monkeypatch the threading module?

/usr/lib/python2.7/threading.pyc is stock from my distribution, Ubuntu 12.04 LTS, which has python-2.7.3~rc1-1ubuntu2.
I did manually apply the patch I've attached here to /usr/lib/python2.7/threading.py, and it *seemed* to silence those errors.
However, on checking my logs again this morning, I have a few hundred more of the same error, so that was not effective.
First time contributor here...what would be the proper way to test this?
Thanks for your patience.

> However, on checking my logs again this morning, I have a few hundred
> more of the same error, so that was not effective.
Did you restart your server?
In your patch, you could use the traceback module (e.g. http://docs.python.org/dev/library/traceback.html#traceback.print_stack ) to figure out in which situation the error occurs.

_DummyThread.__init__() explicitly deletes self._Thread__block:
 def __init__(self):
 Thread.__init__(self, name=_newname("Dummy-%d"))
 # Thread.__block consumes an OS-level locking primitive, which
 # can never be used by a _DummyThread. Since a _DummyThread
 # instance is immortal, that's bad, so release this resource.
 del self._Thread__block
 ^^^^^^^^^^^^^^^^^^^^^^^

Ignore my last message...

Okay, update...
I did rebuild all of Python from source (actually, I applied it to the Ubuntu python2.7 package, rebuilt that locally, and then upgraded to the new python2.7 deb's. I could see my change was applied /usr/lib/python2.7/threading.py, and I can safely assume that it landed in the pyc as well.
I restarted Apache2 to reload my wsgi script. But unfortunately, I get the same error in /var/log/apache/error.log:
[Wed Mar 21 12:52:36 2012] [error] Exception AttributeError: AttributeError("'_DummyThread' object has no attribute '_Thread__block'"
,) in <module 'threading' from '/usr/lib/python2.7/threading.pyc'> ignored 
So please consider my patch as wrong/bad/insufficient.
Issue is still open, though. Thanks.

I saw the similar problem on Ubuntu 12.04 with django development server with mediageneartor. As Dustin suggested, I don't think this is related to the "del _Thread__block" statement.
I hacked the __getattribute__ of DummyThread class
 def __getattribute__(self, name):
 if name == '_Thread__block':
 import traceback
 traceback.print_stack()
 raise AttributeError
 return Thread.__getattribute__(self, name)
And I got the following stacktrace:
 File "/tmp/ve/local/lib/python2.7/site-packages/mediagenerator/filters/coffeescript.py", line 54, in _compile
 shell=shell, universal_newlines=True)
 File "/usr/lib/python2.7/subprocess.py", line 679, in __init__
 errread, errwrite)
 File "/usr/lib/python2.7/subprocess.py", line 1143, in _execute_child
 self.pid = os.fork()
 File "/usr/lib/python2.7/threading.py", line 907, in _after_fork
 thread._Thread__stop()
 File "/usr/lib/python2.7/threading.py", line 608, in __stop
 self.__block.acquire()
 File "/usr/lib/python2.7/threading.py", line 827, in __getattribute__
 traceback.print_stack()

Ok, could you try applying the following patch to threading.py?
diff --git a/Lib/threading.py b/Lib/threading.py
--- a/Lib/threading.py
+++ b/Lib/threading.py
@@ -887,7 +887,7 @@ def _after_fork():
 ident = _get_ident()
 thread._Thread__ident = ident
 new_active[ident] = thread
- else:
+ elif not isinstance(thread, _DummyThread):
 # All the others are already stopped.
 thread._Thread__stop()

Here is a complete patch + tests for 2.7.

> Here is a complete patch + tests for 2.7.
I like the test.
However there's something I find strange with the patch:
"""
diff --git a/Lib/threading.py b/Lib/threading.py
--- a/Lib/threading.py
+++ b/Lib/threading.py
@@ -887,7 +887,7 @@ def _after_fork():
 ident = _get_ident()
 thread._Thread__ident = ident
 new_active[ident] = thread
- else:
+ elif not isinstance(thread, _DummyThread):
 # All the others are already stopped.
 thread._Thread__stop()
"""
Is it really the caller's job to check that the thread is not a dummy thread?
IMO it should be _DummyThread's stop() method that does the right thing, either by overriding Thread's stop() method in _DummyThread or by puting the check inside Thread.stop(), like what's done inside thread._reset_internal_locks():
"""
 if hasattr(self, '_Thread__block'): # DummyThread deletes self.__block
 self.__block.__init__()
 self.__started._reset_internal_locks()
"""

Le jeudi 19 avril 2012 à 21:11 +0000, Charles-François Natali a écrit :
> IMO it should be _DummyThread's stop() method that does the right
> thing, either by overriding Thread's stop() method in _DummyThread or
> by puting the check inside Thread.stop(), like what's done inside
> thread._reset_internal_locks():
I don't think _DummyThread can override __stop(), because of the name
mangling of __private methods. However, the hasattr() approach would
probably work.

New patch with the hasattr() approach.

> New patch with the hasattr() approach.
LGTM.

New changeset ab9d6c4907e7 by Antoine Pitrou in branch '2.7':
Issue #14308: Fix an exception when a "dummy" thread is in the threading module's active list after a fork().
http://hg.python.org/cpython/rev/ab9d6c4907e7
New changeset 41c64c700e1e by Antoine Pitrou in branch '3.2':
Issue #14308: Fix an exception when a "dummy" thread is in the threading module's active list after a fork().
http://hg.python.org/cpython/rev/41c64c700e1e
New changeset e3ea462cb181 by Antoine Pitrou in branch 'default':
Issue #14308: Fix an exception when a dummy thread is in the threading module's active list after a fork().
http://hg.python.org/cpython/rev/e3ea462cb181 

> I don't think _DummyThread can override __stop(), because of the name
> mangling of __private methods. However, the hasattr() approach would
> probably work.
Wouldn't a _DummyThread._Thread__stop() method override Thread.__stop()? Like
>>> class A(object):
... def foo(self):
... self.__bar()
... def __bar(self):
... print "original"
...
>>> class B(A):
... def _A__bar(self):
... print "overridden"
...
>>> B().foo()
overridden

> Wouldn't a _DummyThread._Thread__stop() method override Thread.__stop()?
Probably, but that would be quite ugly IMHO.
I've now committed the patch as-is in 2.7. In 3.2 it turned out easier: __stop is now spelt _stop, so can be overriden without any hacks.

Glad this is fixed. Attached is a Python 2.7 file that demonstrates the problem in a pretty minimal way in case it is of any use to anyone.