Repository navigation
Can segfault Python with itertools.chain.from_iterable #69615
Description
| BPO | 25429 |
|---|---|
| Nosy | @rhettinger, @serhiy-storchaka, @MojoVampire |
| Superseder |
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 = 'https://github.com/rhettinger'
closed_at = <Date 2015-10-17.05:11:29.735>
created_at = <Date 2015-10-17.02:11:53.027>
labels = ['extension-modules', 'type-crash']
title = 'Can segfault Python with itertools.chain.from_iterable'
updated_at = <Date 2015-10-17.17:17:52.632>
user = 'https://bugs.python.org/EvanHubinger'bugs.python.org fields:
activity = <Date 2015-10-17.17:17:52.632>
actor = 'zach.ware'
assignee = 'rhettinger'
closed = True
closed_date = <Date 2015-10-17.05:11:29.735>
closer = 'rhettinger'
components = ['Extension Modules']
creation = <Date 2015-10-17.02:11:53.027>
creator = 'Evan Hubinger'
dependencies = []
files = []
hgrepos = []
issue_num = 25429
keywords = []
message_count = 4.0
messages = ['253112', '253119', '253120', '253123']
nosy_count = 4.0
nosy_names = ['rhettinger', 'serhiy.storchaka', 'josh.r', 'Evan Hubinger']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '14010'
type = 'crash'
url = 'https://bugs.python.org/issue25429'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5', 'Python 3.6']
Activity
EvanHubinger commentedon Oct 17, 2015
The code
definitely segfaults on Python 2.6, 2.7, 3.3, and 3.4, and probably segfaults on other versions as well. The code is clearly incorrect in that the lambda references the variable being defined, but it seems like it should raise an error instead of segfaulting.
MojoVampire commentedon Oct 17, 2015
Also crashes in 3.5.0 (on Windows 7, with 64 bit build).
rhettinger commentedon Oct 17, 2015
This is a duplicate of Issue bpo-14010. This issue runs deep and isn't itertools specific. Running infinite chains of iterators pushes a number of CPython internals past their limits. The best solutions are hard (monitoring the C-stack or fixing every possible fault at the fracture point). The simplest solution (adding recursion count tracking to every possible iteration)is very heavy-handed and would slow-down all of Python in order to spare exotic cases that don't seem to arise in practice.
serhiy-storchaka commentedon Oct 17, 2015
Actually this issue an exact duplicate of bpo-22911 that is a duplicate of bpo-14010.