[PD] What exactly is a "stack overflow" ?

[Martin Peach]

Mathieu Bouchard wrote:
>On Mon, 17 Dec 2007, Martin Peach wrote:
>>The cpu signals an overflow whenever the stack space runs out (the program
>>tries to access the stack beyond its boundaries)
>
>With Pd, this is never what happens on its own. Instead, just before 
>processing each message, a check of the count of nested message processings 
>in made (messages sent that are still being processed, not counting those 
>scheduled by [delay] and stuff).

So it's not really a stack overflow, more like a buffer overrun.

>
>Win16 would typically have a 512 byte limit for the stack. This is too 
>little for today's needs, but it could be increased up to 64k if you really 
>wanted. In contrast, Linux can typically grow the stack to 512 megs or 
>more, and I don't see why Win32 wouldn't be able to (though I have idea 
>what Win32 does about it -- it probably has a reasonable stack size). 512 
>megs is too much for the protection that Pd needs.

But if you don't have 512Meg of RAM then what? The OS must only allocate a 
fraction of available memory for stack, preserving enough memory for program 
and variables.
The 6502 in the Apple][ had exactly 256 bytes of stack and would just crash 
on overflow.
With pentiums and the like the OS has to tell the CPU what the stack limits 
are and then the cpu throws an exception if the stack is accessed outside 
the limit. That interrupts the OS, which kills the offending process and  
prints "stack overflow" or whatever.

>
>Older versions of Pd checked stack size instead, but it was a problem with 
>large on-stack allocations. What Linux (or OSX) does when reaching maximum 
>stack size (which you can intentionally lower) is raise a signal, using 
>kill(). It normally doesn't give you any sane way of handling this, so this 
>is why applications that want to stay alive after a so-called stack 
>overflow have to do it themselves and never involve the OS in it.
>
>(If you want to escape an OS-based stack overflow, you can, you need to do 
>things dependent on both which OS and which CPU type, and I wouldn't be 
>surprised if it also depended on which kernel version. I never actually did 
>it, but I'm pretty sure that it's doable, just that it's too scary).

You would need to modify the processor's interrupt table by replacing the 
stack overflow exception handler, which is likely to cause trouble 
elsewhere. The OS wouldn't let you do that anyway, because you'd be 
accessing memory outside of user space, which triggers another kind of 
exception, "segmentation fault", the same one triggered by accessing a null 
pointer.

Martin