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