infinite recursion in PyErr_WriteUnraisable

[ldeller]

BPO	5223
Nosy	@loewis, @amauryfa, @pitrou, @vstinner, @serhiy-storchaka
Files	recursebug.py: small example which crashes the interpreter recursioncheck.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2012-10-16.19:38:59.206>
created_at = <Date 2009-02-12.04:28:34.266>
labels = ['interpreter-core', 'type-crash']
title = 'infinite recursion in PyErr_WriteUnraisable'
updated_at = <Date 2012-10-16.19:38:59.205>
user = 'https://bugs.python.org/ldeller'

bugs.python.org fields:

activity = <Date 2012-10-16.19:38:59.205>
actor = 'pitrou'
assignee = 'none'
closed = True
closed_date = <Date 2012-10-16.19:38:59.206>
closer = 'pitrou'
components = ['Interpreter Core']
creation = <Date 2009-02-12.04:28:34.266>
creator = 'ldeller'
dependencies = []
files = ['13044', '13284']
hgrepos = []
issue_num = 5223
keywords = ['patch']
message_count = 12.0
messages = ['81721', '81723', '81724', '83354', '83375', '83481', '83515', '99128', '111841', '125280', '173063', '173082']
nosy_count = 7.0
nosy_names = ['loewis', 'amaury.forgeotdarc', 'pitrou', 'vstinner', 'ldeller', 'BreamoreBoy', 'serhiy.storchaka']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue5223'
versions = ['Python 2.6']

[ldeller]

Here is an example of pure Python code which can cause the interpreter
to crash.

I can reproduce the problem in 2.6.0 and 2.6.1 but not in 2.5.2.

The __getattr__ function in this example is interesting in that it
involves infinite recursion, but then the RuntimeError("maximum
recursion depth exceeded") actually causes it to behave correctly. This
is due to the behaviour of hasattr which suppresses any exception caught
when checking for attributes.

Added to the mix we have sys.stderr replaced by an instance with a write
method. The key ingredient here is that getattr(sys.stderr, "write")
invokes Python code. Near the interpreter's recursion limit this python
code can fail. This causes infinite recursion in C.

Here is a snippet of the call stack from gdb showing the recursion cycle
(using 2.6.0 source code):

#9 0x00000000004a442c in PyErr_WriteUnraisable (obj=0x64ae40)
at Python/errors.c:606
#10 0x00000000004a48f5 in PyErr_GivenExceptionMatches (err=0x64ae40,
exc=0x64ae40) at Python/errors.c:115
#11 0x0000000000466056 in slot_tp_getattr_hook (self=0x70a910,
name=0x2b4a94d47e70) at Objects/typeobject.c:5426
#12 0x0000000000449f4d in PyObject_GetAttrString (v=0x70a910,
name=0x7fff155e2fe0 <Address 0x7fff155e2fe0 out of bounds>)
at Objects/object.c:1176
#13 0x000000000042e316 in PyFile_WriteObject (v=0xd02d88, f=0x70a910,
flags=1)
at Objects/fileobject.c:2362
#14 0x000000000042e5c5 in PyFile_WriteString (s=0x51704a "Exception ",
f=0x70a910) at Objects/fileobject.c:2422
#15 0x00000000004a442c in PyErr_WriteUnraisable (obj=0x64ae40)
at Python/errors.c:606

[ldeller]

I believe that this problem was introduced in subversion revision 65319.

[ldeller]

sorry I meant revision 65320

[ldeller]

Hi amaury, I am copying you into this issue because I think it was
introduced in your revision 65320 when you added a call to
PyErr_WriteUnraisable from PyErr_GivenExceptionMatches in Python/errors.c.
Any thoughts on on this issue or how to fix it would be very welcome.

[amauryfa]

python 3.0 does not crash. And it has better code for infinite recursion
(r55850, r66186)
I suggest to backport the py3k code, patch attached.

Martin, your comments are welcome. Are there compatibility issues?

[pitrou]

Amaury, there is a funny bug in the 3.0 implementation with very low
recursion limits (bpo-5392).

[amauryfa]

yes, let's add this change to the backport.

[pitrou]

As already mentioned, the backport patch isn't up to date.

[BreamoreBoy]

Could the experts who have previously commented please advise as to whether this issue should be open, closed or whatever.

[pitrou]

Works fine under 2.7-3.2. Not sure this is worth fixing in 2.6.

[serhiy-storchaka]

On 2.7 prints two 42, on 3.x fails (RuntimeError: maximum recursion depth exceeded in comparison) on first call. 2.6 out of date for non-security fix.

[pitrou]

Ok, so I would say this whole issue is out of date now, since maintained branches don't show the issue.