[issue43048] Printing RecursionError results in RecursionError

[Łukasz Langa]

Change by Łukasz Langa :


--
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43048] Printing RecursionError results in RecursionError

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 489c27358376e772a61753c3f67daa836ca1eab7 by Vladimir Feinberg in 
branch '3.9':
[3.9] bpo-43048: RecursionError traceback RecursionError bugfix for cpy3.9 
(GH-24460) (#24460)
https://github.com/python/cpython/commit/489c27358376e772a61753c3f67daa836ca1eab7


--
nosy: +lukasz.langa

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43048] Printing RecursionError results in RecursionError

[Vladimir Feinberg]

Change by Vladimir Feinberg :


--
keywords: +patch
pull_requests: +23256
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/24460

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43048] Printing RecursionError results in RecursionError

[Vladimir Feinberg]

Vladimir Feinberg  added the comment:

Yep, you're right. I'd be happy to (but I've never done it before, so
please give me some time).

On Tue, Feb 2, 2021 at 12:35 AM Irit Katriel  wrote:

>
> Irit Katriel  added the comment:
>
> It should truncate at the call that raised the recursion error, not the
> first one. Do you want to create a patch?
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43048] Printing RecursionError results in RecursionError

[Irit Katriel]

Irit Katriel  added the comment:

It should truncate at the call that raised the recursion error, not the first 
one. Do you want to create a patch?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43048] Printing RecursionError results in RecursionError

[Vladimir Feinberg]

Vladimir Feinberg  added the comment:

Oh, yes, I suppose, that'll truncate to just the first TracebackException.

On Mon, Feb 1, 2021 at 4:38 PM Irit Katriel  wrote:

>
> Irit Katriel  added the comment:
>
> I meant to catch the exception in the constructor’s recursive call, and if
> necessary then the same again in format (if there are more function calls
> per exception in format, it will be necessary. The unit test from the 3.10
> patch will tell).
>
> Would that not work?
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43048] Printing RecursionError results in RecursionError

[Irit Katriel]

Irit Katriel  added the comment:

I meant to catch the exception in the constructor’s recursive call, and if 
necessary then the same again in format (if there are more function calls per 
exception in format, it will be necessary. The unit test from the 3.10 patch 
will tell).

Would that not work?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43048] Printing RecursionError results in RecursionError

[Vladimir Feinberg]

Vladimir Feinberg  added the comment:

A simple catch may not work (the very first TracebackException is the one
that gets the RecursionError during initialization of its __context__), but
one thing I was thinking about was walking the __context__ pointers and
nulling out anything past the sys.getrecursionlimit() with a warning.

On Sat, Jan 30, 2021 at 10:00 AM Irit Katriel 
wrote:

>
> Change by Irit Katriel :
>
>
> --
> keywords: +easy
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43048] Printing RecursionError results in RecursionError

[Irit Katriel]

Change by Irit Katriel :


--
keywords: +easy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43048] Printing RecursionError results in RecursionError

[Irit Katriel]

Irit Katriel  added the comment:

Maybe it is worth doing something less invasive in 3.9, such as catching the 
recursion error and truncating the output?

--
status: closed -> open
versions:  -Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43048] Printing RecursionError results in RecursionError

[Vladimir Feinberg]

Vladimir Feinberg  added the comment:

I agree with both the duplicate classification and am glad the fix works in 
3.10. Thanks all for the responses.

Given the issue can be triggered with a fairly benign setup (pandas triggers 
such an error, and logger.exception is idiomatic), I do think backport should 
be worth consideration, but maybe I'm overindexing on the frequency of such 
exceptions in the wild.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43048] Printing RecursionError results in RecursionError

[Terry J. Reedy]

Terry J. Reedy  added the comment:

With 3.9, exc.py produces for me

Traceback (most recent call last):
  File "F:\Python\a\tem3.py", line 3, in f
raise ValueError('hello')
ValueError: hello

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "F:\Python\a\tem3.py", line 3, in f
raise ValueError('hello')
ValueError: hello
...
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "F:\Python\a\tem3.py", line 11, in 
f()
  File "F:\Python\a\tem3.py", line 5, in f
f()
  File "F:\Python\a\tem3.py", line 5, in f
f()
  File "F:\Python\a\tem3.py", line 5, in f
f()
  [Previous line repeated 992 more times]
  File "F:\Python\a\tem3.py", line 3, in f
raise ValueError('hello')
RecursionError: maximum recursion depth exceeded while calling a Python object

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Programs\Python310\lib\runpy.py", line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
  File "C:\Programs\Python310\lib\runpy.py", line 87, in _run_code
exec(code, run_globals)
  File "F:\Python\a\tem3.py", line 14, in 
print_exception(exc_info[0], exc_info[1], exc_info[2], None)
  File "C:\Programs\Python310\lib\traceback.py", line 113, in print_exception
for line in TracebackException(
  File "C:\Programs\Python310\lib\traceback.py", line 503, in __init__
context = TracebackException(
  File "C:\Programs\Python310\lib\traceback.py", line 503, in __init__
context = TracebackException(
  File "C:\Programs\Python310\lib\traceback.py", line 503, in __init__
context = TracebackException(
  [Previous line repeated 494 more times]
RecursionError: maximum recursion depth exceeded

This ends the same way as in #42848.


The patch in #42848 will appear in 3.10.0a5 in March.  Guido and Irit decided 
not to backport at the patch is as much a refactoring as a fix.

On a fresh repository build, exc.py ends with 

Traceback (most recent call last):
  File "f:\python\a\tem3.py", line 3, in f
raise ValueError('hello')
ValueError: hello

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "f:\python\a\tem3.py", line 11, in 
f()
  File "f:\python\a\tem3.py", line 5, in f
f()
  File "f:\python\a\tem3.py", line 5, in f
f()
  File "f:\python\a\tem3.py", line 5, in f
f()
  [Previous line repeated 995 more times]
  File "f:\python\a\tem3.py", line 3, in f
raise ValueError('hello')
RecursionError: maximum recursion depth exceeded while calling a Python object
got to the finish line!

I believe this is the expected improvement.

--
nosy: +terry.reedy
stage:  -> resolved
status: pending -> closed
type:  -> behavior
versions: +Python 3.10 -Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43048] Printing RecursionError results in RecursionError

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> duplicate
status: open -> pending
superseder:  -> asyncio produces an unexpected traceback with recursive 
__getattribute__

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43048] Printing RecursionError results in RecursionError

[Irit Katriel]

Irit Katriel  added the comment:

This looks like a duplicate of issue 42848 which was fixed in 3.10.

--
nosy: +iritkatriel

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43048] Printing RecursionError results in RecursionError

[Vladimir Feinberg]

New submission from Vladimir Feinberg :

Python's standard logger provides an exception() method, which is to be called 
from except blocks to log out exception traces by pulling from sys.exc_info().

Per https://github.com/python/cpython/blob/3.9/Lib/logging/__init__.py#L617 , 
logger.exception('my message') eventually boils down to something like 
traceback.print_exception(ei[0], ei[1], ei[2], None, some_buffer) where ei is 
the sys.exc_info().

However, the traceback code generates that printout by constructing a 
TracebackException recursively for every `except` context.

In turn, if a RecursionError was generated from an exception thrown across many 
except blocks, the TracebackException construction itself will have a 
RecursionError. This is particularly bad in cases where you'd want to capture 
this failure information, such as when you're printing the exception, since 
you'll never find out about the originating error.

Certain (well-used) libraries rely on try/except for control flow, and 
occasionally do recurse in their except blocks, so such exceptions are not 
hypothetical.

A solution to this might be to avoid constructing a TracebackException, and 
instead unwind traceback context using a while loop.

--
components: Library (Lib)
files: exc.py
messages: 385828
nosy: vlad2
priority: normal
severity: normal
status: open
title: Printing RecursionError results in RecursionError
versions: Python 3.6, Python 3.7, Python 3.9
Added file: https://bugs.python.org/file49769/exc.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com