assertion failures
Archie Cobbs
kaffe@rufus.w3.org
Tue, 28 Jul 1998 14:03:11 -0700 (PDT)
Godmar Back writes:
> > - Compile in code at the beginning of each method to check the
> > stack pointer (this could be done optionally, controlled by
> > a command line argument). It should have a negligible effect
> > on speed.
>
> This is what Dan Lambright did at the OpenGroup, although they used it
> for other reasons. (His mail is in the archives.)
Was there some reason it wasn't folded back into kaffe?
> > - Put each thread stack in its own memory mapped region with
> > unmapped pages on either side
>
> The problem with that is that you must be able to recover from the
> trap you take once you overflow. This is somewhat tricky, as you
> obviously cannot handle the trap on the stack you've just overflowed.
> A possible solution is to use alternate signal stacks and have the OS
> switch stacks for you. If I should have the time, I might look into
> how that could be done best in a portable manner.
Also, it's not always possible to arrange the memory map like you
want it necessarily (from what I remember of mmap()), so this is
not a 100% reliable solution.
-Archie
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com