[Twisted-Python] Python 3: Odd failure to print unhandled error tb
I've been looking at cleaning up cases where a traceback isn't printed for deferreds with an unhandled error, and there is one strange case I'm hoping someone might have thoughts about*. For reference, some of this is part of 7927 and related tickets. Consider: from __future__ import print_function import sys from twisted.internet import reactor, defer from twisted.logger import ( globalLogBeginner, textFileLogObserver, ) def raiseException(res): raise Exception("I am a traceback!") if sys.argv[1] == '1': globalLogBeginner.beginLoggingTo([textFileLogObserver(sys.stdout)]) d = defer.Deferred() d.addCallback(raiseException) d.callback(None) elif sys.argv[1] == '2': globalLogBeginner.beginLoggingTo([textFileLogObserver(sys.stdout)]) def go(): d = defer.Deferred() d.addCallback(raiseException) d.callback(None) go() elif sys.argv[1] == '3': globalLogBeginner.beginLoggingTo([textFileLogObserver(sys.stdout)]) def go2(): d = defer.Deferred() d.addCallback(raiseException) d.callback(None) reactor.stop() reactor.callWhenRunning(go2) reactor.run() For '1' above, nothing will be printed for python3, python2 is fine. All other cases print a traceback as expected. While case 1 isn't necessarily not a "normal" case of twisted usage, but it is a short and clear way to demonstrate the logger that has at least a few examples: https://twistedmatrix.com/trac/ticket/7927 (original description) https://twistedmatrix.com/pipermail/twisted-python/2018-May/031922.html After a little debugging, I did see a few places where an exception complaining about sys.meta path being none and the interpreter shutting down, but I'm not confident enough in my tests to know whether that wasn't triggered by me. Any thoughts on why no traceback is printed for case 1? Is it even worth worrying about? Thanks, -Jason Litzinger * Tested with Python 3.6 on Arch Linux, Python 3.5.2 on ubuntu
On May 30, 2018, at 10:04 PM, Jason Litzinger <jlitzingerdev@gmail.com> wrote:
Any thoughts on why no traceback is printed for case 1? Is it even worth worrying about?
My guess is that since `d` is at the global scope, it doesn't get garbage collected until some unfortunately late phase in the interpreter tear-down where maybe stderr isn't even available any more. I'd definitely ignore this case for now and fix the others, which are much more serious, and tractable to fix ;). -g
My guess is that since `d` is at the global scope, it doesn't get garbage collected until some unfortunately late phase in the interpreter tear-down where maybe stderr isn't even available any more. Here be dragons.
I'd definitely ignore this case for now and fix the others, which are much more serious, and tractable to fix ;). That's where I've been leaning, so I'll avoid this case for now. I'll probably reference this in #7927 for completeness.
Thanks! -Jason
participants (2)
-
Glyph
-
Jason Litzinger