[Gc] Can sigaltstack be used in a GC registered thread?

[Petter Urkedal]

I should have mentioned that the code I was using is mostly pure.  It
allocates memory and does some logging.  Data created or altered by a
failed computation would not be used.  Though, I see your point:  I
should have checked available stack space before allocating to avoid
corrupting GC internal structures.  Likewise for logging.  Strangely, it
worked anyway.

On 2012-05-21, Boehm, Hans wrote:
> The core issue here is that stack overflow signals are essentially
> asynchronous.  As far as the programmer is concerned, they can occur anywhere.
> Worse yet, they may occur at a "point in the code" that doesn't really
> exist, because the compiler has transformed the code.  That means invariants
> may be arbitrarily broken, locks may be held, etc.  Posix doesn't, and
> can't, guarantee that longjmping out of such a signal handler is safe.
> In some cases it may work, but its hard to guarantee correctness, GC or
> not.
> 
> I believe that Java implementations that try to generate stack overflow
> exceptions usually handle this by always making sure that they encounter
> stack overflow exceptions at a known point.  For example, they check at
> the beginning of each function that the function, including any native
> library code it invokes, has enough stack space to run to completion.  This isn't
> entirely free, though it may be fairly cheap.  It still doesn't strike me
> as 100% solid, since the libc API doesn't really include maximum stack
> depth bounds, so you have to determine those empirically, and hope libc
> doesn't change unexpectedly.  And it's easy to miss a path through libc
> that has an unexpectedly deep call stack because something unexpected
> happened inside the library call.
> 
> Even if it works, you still have the problem that Java code may have
> trouble dealing with the exception in unexpected places.
> 
> Hans
> 
> > -----Original Message-----
> > From: gc-bounces at linux.hpl.hp.com [mailto:gc-bounces at linux.hpl.hp.com]
> > On Behalf Of Petter Urkedal
> > Sent: Monday, May 21, 2012 12:17 AM
> > To: gc at linux.hpl.hp.com
> > Subject: Re: [Gc] Can sigaltstack be used in a GC registered thread?
> > 
> > On 2012-05-21, Boehm, Hans wrote:
> > > AFAIK, the collector makes no attempt to handle a stack overflow.  It
> > does make an attempt to invoke a preexisting SIGSEGV handler if one was
> > previously installed.  It's conceivably possible, though no doubt
> > untested, to install a stack overflow handler that somehow maps
> > additional stack space and returns.  I can't think of another approach
> > that would work with the current code structure.  And I believe this is
> > a common problem for lots of system libraries.  I believe you're also
> > out of luck if you generate a stack overflow while calling the libc
> > malloc.
> > 
> > For some purposes, it's sufficient to be able to longjmp back to a good
> > point or raise an exception.  E.g. I used libgc for a theorem prover
> > (unpublished), and while running though the TPTP suite, it would
> > occasionally cause a stack overflow, which I "handled" by skipping to
> > the next problem.  The signal stack handler I used is here:
> > https://github.com/paurkedal/culibs/blob/master/cuflow/errors.c (Note:
> > I
> > should be calling the existing handler at the bottom of segv_handler.)
> > _______________________________________________
> > Gc mailing list
> > Gc at linux.hpl.hp.com
> > http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/