[ python-Bugs-1110055 ] recursion core dumps

SourceForge.net noreply at sourceforge.net
Sat Jan 29 21:12:40 CET 2005


Bugs item #1110055, was opened at 2005-01-26 11:18
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110055&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jacob Engelbrecht (jengeldk)
Assigned to: Nobody/Anonymous (nobody)
Summary: recursion core dumps

Initial Comment:
when running recursive function you get a coredump with
deep recursion. 
eg

from sys import *
n = 30000
setrecursionlimit(n+1)

def fact(n):
   if n==1:
      return 1
   return fact(n-1)*n

fact(n)

This is seen on linux i686 with both python2.3 and
python2.4, the recursion depth which triggers the core
dump is 26211 with python2.4 and 29123 with python2.3
with a machine having 2076860 kB of memory, on machines
with less memory smaller numbers are seen.

this is what gdb tells me:
jacob at pauling:/scratch/jacob$ gdb /usr/bin/python2.4 core
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i386-linux"...(no debugging
symbols found)
Using host libthread_db library
"/lib/tls/libthread_db.so.1".

(no debugging symbols found)
Core was generated by `python2.4 /home/user_4/jacob/rr
30000'.
Program terminated with signal 11, Segmentation fault.

warning: current_sos: Can't read pathname for load map:
Input/output error

Reading symbols from /lib/tls/libpthread.so.0...(no
debugging symbols found)...done.
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /lib/tls/libdl.so.2...(no
debugging symbols found)...done.
Loaded symbols for /lib/tls/libdl.so.2
Reading symbols from /lib/tls/libutil.so.1...(no
debugging symbols found)...done.
Loaded symbols for /lib/tls/libutil.so.1
Reading symbols from /lib/tls/libm.so.6...
(no debugging symbols found)...done.
Loaded symbols for /lib/tls/libm.so.6
Reading symbols from /lib/tls/libc.so.6...(no debugging
symbols found)...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging
symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2

#0  0x400c94bf in mallopt () from /lib/tls/libc.so.6


----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2005-01-29 14:12

Message:
Logged In: YES 
user_id=699438

This looks like a stack overflow.  There's not much python 
can do when the stack runs out of memory, which is why the 
default recursion limit is set to 1000.

Also, at least in the reproducable, the number you are building 
is going to consume excessive amounts of memory.

I ran this test (to avoid creating a giant long number) and still 
got the segfault.

from sys import *
n = 30000
setrecursionlimit(n+1)

def nofact(n):
    if n==1: 
        return 1
    return nofact(n-1)

nofact(n)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110055&group_id=5470


More information about the Python-bugs-list mailing list