[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


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

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

I am currently working on improving the code handling call stack overflow
in my Common Lisp environment MKCL (https://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: https://napali.hpl.hp.com/pipermail/gc/attachments/20120520/2e7cf01c/attachment.htm

More information about the Gc mailing list