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