From: Mathieu Bouchard <matju@...>
Date: 2002-01-18T00:54:41+09:00
Subject: Re: Possible bug in Mac version?


On Thu, 17 Jan 2002, Dave Thomas wrote:
> ts <decoux@moulon.inra.fr> writes:
> > >>>>> "D" == Dave Thomas <Dave@PragmaticProgrammer.com> writes:
> > D>     The following program makes Ruby crash whenever you use the number
> > D>     400.
> >  This is not a problem of stack size ?
> Most likely, although a SEGV seems somewhat harse :)

my personal notes on stack overflow:

i remember a stack size of 1/2 kB was common on DOS, Windows 3, etc.

when i switched to linux, i noticed the stack size was as much RAM as I
had on my system. I think the hard limit is around 1/4 GB or 1/2 GB. This
is because of reliance on virtual memory and lazy allocation (stack is
grown by 4 kB amounts whenever needed)

checking for stack overflow on DOS requires checking the address of an
'auto' variable (that is, local non-static) and making sure it's in the
right range. if it's outside, then you blew it up and you already
corrupted RAM. you can slightly cut the range so that you generate a stack
overflow exception and still have space to handle it without crashing.

when handling stack overflow on a unix system, you better know what is the
stack limit, unless your signal handler for SEGV somehow sets its own
stack pointer, and even so, maybe the kernel will have already refused to
call your signal handler because it can't write the stack info for your
signal (?) note that I haven't tried to do that.

I could not really tell what is the point of setting the stack to less
than 1 MB these days.

IIRC, Ruby probably does not check for C/OS-level stack overflows; it does
check for Ruby-level stack overflows, using its own counters. Which means
you better give it something like 32 kB of RAM, or whatever is maximum
ruby stack frames times maximum ruby stack frame size plus a comfortable
buffer.

________________________________________________________________
Mathieu Bouchard                   http://hostname.2y.net/~matju