RE: safety of GCJ-generated code

["Boehm, Hans" <hans_boehm at hp dot com>]

Note that the garbage collector is not aware of sigaltstack.  It either
needs to be adapted, or we need to make sure that it never catches a thread
on the alternate stack.  It may suffice to simply mask all signals in the
SIGSEGV handler.

Another problem with all of this is that on some platforms throwing an
exception may require a large amount of allocation, e.g. to read in debug
information for the stack unwinder.  But on X86 that's hopefully not an
issue.

Hans

> -----Original Message-----
> From: Andrew Haley [mailto:aph@cambridge.redhat.com]
> Sent: Tuesday, December 18, 2001 10:11 AM
> To: Adam Megacz; java@gcc.gnu.org
> Subject: Re: safety of GCJ-generated code
> 
> 
> [I hit "send" too soon.  Sorry.]
> 
> Andrew Haley writes:
>  > Adam Megacz writes:
>  >  > 
>  >  > Interestingly, in my mucking around with the win32 
> stuff, I though I
>  >  > saw something about a special "Stack Overflow Signal" on
>  >  > win32... perhaps it might be as simple as just catching 
> that signal
>  >  > and then "throw new StackOverflowException()"...
>  > 
>  > Erm, but you'd have no stack to call new().  :-)
>  > 
>  > However, given that simply receiving a signal requires 
> stack space to
>  > be allocated in order to save the user context, I assume 
> that a kernel
>  > must unprotect the guard area at the end of a thread's stack before
>  > sending the signal?  Hmm, I need to have a chat with a kernel
>  > engineer.
> 
> Right, I have now done so, and I have found out what is needed for
> Linux.
> 
> Unless you set up an alternative signal stack then if there's no space
> for the user context on the your stack the kernel will force your SEGV
> handler to SIG_DFL and send you another SEGV, which will kill your
> process immediately.
> 
> So, for Java we should use sigaltstack(2) for our SEGV handler.  This
> delivers signals on a separate signal stack.
> 
> Perhaps we'll then have to find a way to switch back on to the stack
> that has overflowed in order to throw the exception.  On the other
> hand, perhaps we won't: the unwinder may Just Work even through a
> handler that uses an altstack.  I presume that we can arrange things
> so that more SEGVs will not be delivered while we're still on the
> altstack.
>  
> I don't know what to do for other OSes, but I guess it's similar.
> 
> Andrew.
>