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

[Mathieu Bouchard]

On Mon, 17 Dec 2007, Martin Peach wrote:

>> 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.

A stack is a buffer, and an overflow of addresses is an overrun... what 
are you trying to say?

> But if you don't have 512Meg of RAM then what?

Then you have swap, and if you don't have swap, you necessarily get a 
stack overflow, but it's assumed that if you didn't allocate on the stack, 
you would allocate the same amount of memory on the heap, so it shouldn't 
be much different.

> The OS must only allocate a fraction of available memory for stack, 
> preserving enough memory for program and variables.

It allocates nothing beforehand, and then at each segmentation fault that 
occurs at the CPU level, the OS traps a stack-related segmentation fault 
and adds 4k of RAM to the stack and retries the same code. It's either an 
auto-expand mmap or the equivalent of it.

> The 6502 in the Apple][ had exactly 256 bytes of stack and would just 
> crash on overflow.

I never knew how big the stack was on the CoCo, but given what I know, it 
must necessarily have been much less than 256 bytes, e.g. 32 or 64 bytes, 
because BASIC reserved everything after the first 256 bytes, and most of 
the first 256 bytes were reserved for something else...

> 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.

The OS usually grows the stack. Such a process allows to not have to 
reserve any memory in advance, so that the stack can be pretty much any 
size without wasting more than 4k at a time (except that the stack never 
is ungrown, afaik).

> 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.

In theory, wouldn't you just register a signal-handler for SIGSTKFLT 
instead?

But either way (even if the other way was possible), I think that you'd 
get in trouble because the interrupt/signal-handler would need to push at 
least 3 words on a stack that is already full.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada