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

Boehm, Hans hans.boehm at hp.com
Sun May 20 21:28:48 PDT 2012


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.

The collector should support a mode in which the collection always runs only in collector threads, rather than running on one of the client threads.  That should perhaps even be the default if thread support is enabled.  But it currently doesn't support that mode.  That would reduce stack space consumption and the chance of overflowing the stack in the collector.  I don't think it would be that difficult to implement, but AFAIK it hasn't been done.

I believe that any use of sigaltstack would have to avoid any GC calls and make sure that the collectors signals are disabled while it's running on the alternate signal stack.  We don't try to do that behind the scenes, but I would guess it's quite possible.

Hans

From: gc-bounces at linux.hpl.hp.com [mailto:gc-bounces at linux.hpl.hp.com] On Behalf Of Jean-Claude Beaudoin
Sent: Sunday, May 20, 2012 6:34 PM
To: gc at linux.hpl.hp.com
Subject: [Gc] Can sigaltstack be used in a GC registered thread?


Hi,

After reading the GC sources for a while trying to figure out the
minimal stack requirements for GC function calls I came across
the following consideration:

"sigaltstack" cannot be used in a thread registered with the GC
since the stack analysis the GC would perform during a collect
would be invalid if the collection were to happen during the
dynamic-extent of a signal handler using that "alternate stack".

Am I wrong on this or is this in fact the case?

BTW, a bit of googling shows that mono seems to be facing
the same issue.

I am a bit surprised that I did not get a single reply to my previous
message to this list about call stack overflow handling.
I insert here below a copy of the message in case it was simply
misrouted.

The structure of this GC makes it live at the outer edge of an
application call tree making the probability that a call stack
overflow may happen during the execution of a GC function
quite significant.  Currently if such a thing happens the GC
simply seems to crash the whole application without hope
of handling the event gracefully. In an application that would
otherwise survive this it is a significant disappointment.
Thus my question as to how much stack is needed to
guarantee that such a thing never happens.

Thank you for your help,

Jean-Claude Beaudoin


-----------------------------------------------------------------------------------



From: Jean-Claude Beaudoin <jean.claude.beaudoin-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org<mailto:jean.claude.beaudoin-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>>

Newsgroups: gmane.comp.programming.garbage-collection.boehmgc

Subject: Handling of a stack overflow during GC?

Date: Sat, 19 May 2012 07:13:50 -0400

Hi,



I am currently working on improving the code handling call stack overflow

in my Common Lisp environment MKCL (http://common-lisp.net/project/mkcl/).

MKCL uses a somewhat older (7.2a4) version of the Boehm conservative GC.



I would like to know what would happen if a stack overflow were to occur during

a GC call/collection? The GC code seems to replace the SIGSEGV handler at

some point, will this new SIGSEGV handler still use the alternate signal

stack that MKCL has setup?



Also, as a side question, do you have an estimate of the stack depth

requirements of the GC?  It seems to be at least twice the usual

value of PTHREAD_STACK_MIN (which happens to be 16k on Linux).



Thanks for your help,



Jean-Claude Beaudoin



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20120521/5cf1e0cd/attachment.htm


More information about the Gc mailing list