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

Jean-Claude Beaudoin jean.claude.beaudoin at gmail.com
Sun May 20 18:34:12 PDT 2012


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>
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/20120520/2e7cf01c/attachment.htm


More information about the Gc mailing list