Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segfault of sys.setrecursionlimit if limit exceeds the value 18063 (GNU/Linux) #50605

Closed
str1442 mannequin opened this issue Jun 28, 2009 · 2 comments
Closed

Segfault of sys.setrecursionlimit if limit exceeds the value 18063 (GNU/Linux) #50605

str1442 mannequin opened this issue Jun 28, 2009 · 2 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) stdlib Python modules in the Lib dir type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@str1442
Copy link
Mannequin

str1442 mannequin commented Jun 28, 2009

BPO 6356
Nosy @loewis

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 2009-06-28.10:54:11.311>
created_at = <Date 2009-06-28.09:51:34.737>
labels = ['interpreter-core', 'library', 'type-crash']
title = 'Segfault of sys.setrecursionlimit\tif limit exceeds the value 18063 (GNU/Linux)'
updated_at = <Date 2009-06-28.10:54:11.310>
user = 'https://bugs.python.org/str1442'

bugs.python.org fields:

activity = <Date 2009-06-28.10:54:11.310>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = <Date 2009-06-28.10:54:11.311>
closer = 'loewis'
components = ['Interpreter Core', 'Library (Lib)']
creation = <Date 2009-06-28.09:51:34.737>
creator = 'str1442'
dependencies = []
files = []
hgrepos = []
issue_num = 6356
keywords = []
message_count = 2.0
messages = ['89772', '89773']
nosy_count = 2.0
nosy_names = ['loewis', 'str1442']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue6356'
versions = ['Python 2.5']

@str1442
Copy link
Mannequin Author

str1442 mannequin commented Jun 28, 2009

After playing around with the setrecursionlimit() Function in the sys
module, i noticed it crashes if you set the limit to a value that is too
high. I explored this further until i noticed the value from which the
crashing begins is exactly 18063. I know that the highest setable value
is platformdependent, but crashing seems inappropriate if a value is
given that is too high.

I'm using Debian GNU/Linux Testing, last upgrade one month ago.

uname -svomr:

Linux 2.6.27.7 #4 SMP Fri Nov 28 01:44:17 CET 2008 i686 GNU/Linux

(Kernel is a pure kernel.org Kernel, self compiled)

Python Version in question is 2.5.4. Searching through the tracker for
setrecursionlimit brought no corresponding issues.

This is a the test script I used:

import sys

sys.setrecursionlimit(18063)

def f():
    g()

def g():
    f()

f()

@str1442 str1442 mannequin added interpreter-core (Objects, Python, Grammar, and Parser dirs) stdlib Python modules in the Lib dir type-crash A hard crash of the interpreter, possibly with a core dump labels Jun 28, 2009
@loewis
Copy link
Mannequin

loewis mannequin commented Jun 28, 2009

I know that the highest setable value
is platformdependent, but crashing seems inappropriate if a value is
given that is too high.

No, it's not inappropriate. It's the only possible reaction.

Closing as won't fix.

@loewis loewis mannequin changed the title Segfault of sys.setrecursionlimit if limit exceeds the value 18063 (GNU/Linux) Segfault of sys.setrecursionlimit if limit exceeds the value 18063 (GNU/Linux) Jun 28, 2009
@loewis loewis mannequin closed this as completed Jun 28, 2009
@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) stdlib Python modules in the Lib dir type-crash A hard crash of the interpreter, possibly with a core dump
Projects
None yet
Development

No branches or pull requests

0 participants