stack check on Unix: any suggestions?
On Thu, Aug 31, 2000 at 02:33:28PM +0200, M.-A. Lemburg wrote:
... At least for my Linux installation a limit of 9000 seems reasonable. Perhaps everybody on the list could do a quick check on their platform ?
Here's a sample script:
i = 0 def foo(x): global i print i i = i + 1 foo(x)
foo(None)
On my DEC/Compaq/OSF1/Tru64 Unix box with the default stacksize of 2048k I get 6225 iterations before seg faulting... -- Mark
I've just checked in Misc/find_recursionlimit.py that uses recursion through various __ methods (.e.g __repr__) to generate infinite recursion. These tend to use more C stack frames that a simple recursive function. I've set the Python recursion_limit down to 2500, which is safe for all tests in find_recursionlimit on my Linux box. The limit can be bumped back up, so I'm happy to have it set low by default. Does anyone have a platform where this limit is no low enough? Jeremy
Compaq/DEC/OSF1/Tru64 Unix, default stacksize 2048k: I get "Limit of 2100 is fine" before stack overflow and segfault. (On Guido's test script, I got 3532 before crashing, and 6225 on MAL's test). Mark Jeremy Hylton wrote:
I've just checked in Misc/find_recursionlimit.py that uses recursion through various __ methods (.e.g __repr__) to generate infinite recursion. These tend to use more C stack frames that a simple recursive function.
I've set the Python recursion_limit down to 2500, which is safe for all tests in find_recursionlimit on my Linux box. The limit can be bumped back up, so I'm happy to have it set low by default.
Does anyone have a platform where this limit is no low enough?
Jeremy> Does anyone have a platform where this limit is no low enough? Yes, apparently I do. My laptop is configured so: Pentium III 128MB RAM 211MB swap Mandrake Linux 7.1 It spits out 2400 as the last successful test, even fresh after a reboot with no swap space in use and lots of free memory and nothing else running besides boot-time daemons. Skip
Skip Montanaro writes:
211MB swap Mandrake Linux 7.1
It spits out 2400 as the last successful test, even fresh after a reboot with no swap space in use and lots of free memory and nothing else running besides boot-time daemons.
I get the exact same value. Of course the amount of other stuff running makes no differemce, you get the core dump because you've hit the RLIMIT for stack usage, not because you've exhausted memory. Amount of RAM in the machine, or swap space in use has nothing to do with it. Do "ulimit -s unlimited" and see what happens... There can be no universally applicable default value here because different people will have different rlimits depending on how their sysadmins chose to set this up.
participants (4)
-
Charles G Waldman -
Jeremy Hylton -
Mark Favas -
Skip Montanaro