[Patches] [ python-Patches-954922 ] Fix for 754449: hiding exc in
threading during interp shutdn
SourceForge.net
noreply at sourceforge.net
Sat Jul 3 00:07:45 EDT 2004
Patches item #954922, was opened at 2004-05-16 14:43
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954922&group_id=5470
Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Brett Cannon (bcannon)
Summary: Fix for 754449: hiding exc in threading during interp shutdn
Initial Comment:
Decided to start a fresh tracker item for this patch since I already
attempted to close bug 754449 once before and I want to make
sure the two fixes stay separate.
Someone emailed me a program whose testing suite could reliably
reproduce the problem as reported in the bug report (for a quck
refresher, basically if someone leaves a threading.Thread instance
running while the interpreter is being shutdown and an exception is
raised in the thread then that exception will cause *another*
exception in the subsequent attempt to report the exception from
the thread because all globals have been set to None at that point).
The previous fix that I checked in turned out not to be thorough
enough (still needed, though). I am currently waiting for the
person who emailed me the triggering code to let me know if I can
publish how to cause the error.
Attached is a patch to remove all instances of accessing globals
(just as if I was writing a __del__ method for threading.Thread) by
storing copies of sys.stderr, sys.exc_info, and sys.tracebacklimit.
All of this is so that a decent approximation of a traceback print-
out can occur without having to call the 'traceback' module since its
functions depend a lot on each other.
I mainly need someone else who is more familiar with dealing with
tracebacks to make sure that I have not done something stupid and
to make sure this is the best way to handle things.
----------------------------------------------------------------------
>Comment By: Tim Peters (tim_one)
Date: 2004-07-03 00:07
Message:
Logged In: YES
user_id=31435
I never care about old versions of Python, and 2.3 is ancient
to me now <wink>. But the lack of sane error messages
when threads are dying is certainly a serious bug, and this is
certainly a bugfix -- it's a fine candidate for backporting.
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2004-07-02 23:56
Message:
Logged In: YES
user_id=357491
In as rev. 1.42 (and two commits to Misc/NEWS; pain to explain this
thing clearly).
Do you think this should be backported? It should apply cleanly, but it
does add a class and instance attribute, so the answer doesn't seem
obvious to me. I say "yes", though.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004-07-02 22:27
Message:
Logged In: YES
user_id=31435
IMO, this is such a huge improvement over the status quo
that it's not worth worrying about niggling format differences
between this output and "the usual" traceback output. The
*information* is the important thing, and this patch is the
difference between no info and all the info there is. Check it
in!
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2004-07-02 21:11
Message:
Logged In: YES
user_id=357491
You're right on the self.__stderr assignment snafu; typo from when I did
the last change to move exc_info to the class instead of the instance. I
hate running the Mnet test suite to trigger the bug since it is long and is
a major resource hog. Fixed the bug, though, and ran the testing suite;
looks good. Here is a sample output:
Exception in thread The Asyncore Poller (most likely raised during
interpreter shutdown):
Traceback (most recent call last):
File "/Users/drifty/Code/compiled_CVS/lib/python2.4/threading.py", line
442, in __bootstrap
File "/Users/drifty/Code/compiled_CVS/lib/python2.4/threading.py", line
422, in run
File "/Users/drifty/Code/Python/mnet/repos/mnet/pyutil/Asyncore.py",
line 133, in _asyncoreloop
File "/Users/drifty/Code/Python/mnet/repos/mnet/pyutil/debugprint.py",
line 59, in write
exceptions.TypeError: 'NoneType' object is not callable
As you will notice the output isn't exactly standard (extra warning about
how exception could have come about and the addition of "exceptions"
for the listing of what the exception was), but nothing glaring. Is it even
worth trying to ditch the appending of "exception"? It would be another
thing to store in the class (types.ClassType if I follow traceback.py).
I also took your advice and ripped out the traceback use. So now the
class stores a reference to _sys.exc_info and the instance stores a ref to
_sys.stderr .
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004-07-01 23:04
Message:
Logged In: YES
user_id=31435
Brett, it looks like self.__stderr is never given a value -- the
__init__ code here binds a *local* vrbl __stderr to
_sys.stderr. If so, that tells me the bulk of the patch hasn't
actually been exercised (else it would have raised
AttributeError trying to print to self.__stderr).
To simplify it more, I think it would be fine to ignore
sys.tracebacklimit. A Google search shows that virtually the
only use of sys.tracebacklimit in real life is the use made of it
here: passively accessing its value to simulate what it would
have done if anyone had ever bothered to set it (of which I
couldn't find even one example).
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2004-07-01 00:33
Message:
Logged In: YES
user_id=357491
Uploading a new version of the patch to store one of the variables in the
class instead of the instance since it it never expected to change. Also
changed the comment.
Still waiting for someone else to take a look at this code before I check it
in.
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2004-05-17 00:37
Message:
Logged In: YES
user_id=357491
Just posted how to reproduce the bug using the in-dev version of mnet as
a post to the bug tracker item.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954922&group_id=5470
More information about the Patches
mailing list