[Gc] Can sigaltstack be used in a GC registered thread?
hans.boehm at hp.com
Mon May 21 08:27:26 PDT 2012
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
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.
> -----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
> 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:
> should be calling the existing handler at the bottom of segv_handler.)
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc