Issue 10933: Tracing disabled when a recursion error is triggered (even if properly handled) (original) (raw)

Created on 2011-01-18 12:31 by fabioz, last changed 2022-04-11 14:57 by admin.

Messages (6)
msg126460 - (view)	Author: Fabio Zadrozny (fabioz) *	Date: 2011-01-18 12:31
It seems that tracing in the interpreter is lost after some recursion error is triggered (even if it's properly handled). This breaks any debugger working after any recursion error is triggered (which suppose shouldn't happen). The attached test case shows the problem in action. Tested the problem with Python 2.6.5 and 3.1.3
msg220891 - (view)	Author: Mark Lawrence (BreamoreBoy) *	Date: 2014-06-17 21:04
Can we have a response to this please.
msg240578 - (view)	Author: James Powell (james)	Date: 2015-04-13 01:08
We investigated this issue with pdmccormick & r.david.murray. The behaviour appears to be intentional. If the trace function raises an Exception, system tracing is disabled entirely. See attached documentation patch to clarify this.
msg240579 - (view)	Author: Peter McCormick (pdmccormick) *	Date: 2015-04-13 01:11
Removed unrelated doc changes.
msg240584 - (view)	Author: R. David Murray (r.david.murray) *	Date: 2015-04-13 02:10
We also discussed whether or not it would be worth indicating in the exception that tracing has been disabled. I believe that implementing this would be aided by resolution of issue 23188. Doing a chained exception for this would also make it clearer that the exception happened inside the trace function. It is not clear that it is sensible to allow tracing to continue if the trace function raises an error, since that pretty much leaves the tracer or debugger or what have you in an undefined state. It is also not clear that there is any reasonable way to try to avoid a recursion error in the trace function when we are near the recursion limit in the underlying code, since the stack depth of the trace function is pretty much arbitrary.
msg240599 - (view)	Author: Fabio Zadrozny (fabioz) *	Date: 2015-04-13 10:58
Well, I'd say that if tracing is enabled and is disabled automatically by Python (thus breaking a working debugger which would usually be used to diagnose the error), I'd at least consider issuing some warning to stderr... (probably warnings.warn cannot be used directly as the stack is at its max depth, but a choice could be raising the max depth, using warnings.warn and then restoring the max depth value in a try..finally -- or at least printing something to stderr regardless of warnings.warn). I.e.: as this is a rare situation and should only happen when you're debugging, I think printing something to stderr regarding that is definitely worth it regardless of chained exceptions (on many cases I had to help users instrument a simple tracer just to detect where it was disabled -- yes, on some of those they were catching all exceptions on some block -- so, program which worked with the recursion stopped having a working debugger).