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.