setrecursionlimit

[Steven D'Aprano]

On Thu, 19 May 2016 02:29 am, Rob Gaddi wrote:

> Ned Batchelder wrote:

>> Is there a way to know how large the C stack can grow, and how much it
>> will grow for each Python function call? That sounds complicated to get
>> right.
>>
>> --Ned.
> 
> It's probably trivial to look at a number and say "Yeah, no, that's
> CLEARLY too high." based on the minimum number of bytes a stack frame
> can require. Guaranteeing that some number lower than that is safe is
> almost certainly impossible. So you'd get an exception for truly
> stupid numbers, but a lack of exception is no guarantee of safety.
> Which is worth what it's worth, I guess.

Not being a C programmer, I don't really understand this.

The idea I have in mind is a model of program memory I learned[1] way back
in the 80s. I don't know if it's still valid. Your application has a bunch
of memory available, which broadly speaking can be divided into three
chunks: globals, the stack, and the heap.

The application knows what globals exist, and can allocate a fixed block of
memory big enough for them, so that's not very interesting. It just sits
there, holding space for the globals, and doesn't grow or shrink.

Then there's the stack, which holds local variables whenever a function is
called, the return address of the caller, and other stuff. There's a fixed
bottom to the stack, but the top can grown and shrink depending on how many
functions you call and how many local variables they use.

Then there's everything else, which is the heap, and it can grown and shrink
in both directions (up to some maximum, of course):

bottom [ globals | stack ----->      <----- heap -----> ] top

If the stack grows into the heap, or vice versa, Bad Things happen. At best
you get a crash. At worst you get arbitrary code execution.


I don't really understand why the system can't track the current top of the
stack and bottom of the heap, and if they're going to collide, halt the
process. That would still be kinda awful, in a sudden "your application
just died" kind of way, but it would be better than "your computer is now
owned by some hacker in Hong Kong, who is now renting it by the hour to
some spammer in Texas".



[1] I say "learned", but in reality I more sort of absorbed it by osmosis.
Nobody ever actually sat down and told me how the stack and heap work, so
the model I have might be completely wrong, even for 1980s tech.


-- 
Steven