Eric Blake wrote:
> In other words, it seems like we should consider
> modifying the contract of c-stack to state that the application should not
> modify SIGBUS handlers.
Yes, right. I'm adding this comment:
2008-12-06 Bruno Haible <[EMAIL PROTECTED]>
* lib/c-stack.h (c_stack_action): Clarify possible side effects.
Suggested by Eric Blake.
--- lib/c-stack.h.orig 2008-12-06 16:50:18.000000000 +0100
+++ lib/c-stack.h 2008-12-06 16:49:15.000000000 +0100
@@ -36,6 +36,9 @@
ACTION must be async-signal-safe. ACTION together with its callees
must not require more than SIGSTKSZ bytes of stack space. Also,
ACTION should not call longjmp, because this implementation does
- not guarantee that it is safe to return to the original stack. */
+ not guarantee that it is safe to return to the original stack.
+
+ This function may install a handler for the SIGSEGV signal or for the SIGBUS
+ signal or exercise other system dependent exception handling APIs. */
extern int c_stack_action (void (* /*action*/) (int));
> On looking at libsigsegv, it looks like it also conditionally installs a
> SIGBUS handler. Which means we found a bug in m4 1.4.12: if you are using
> libsigsegv, and on a platform like MacOS, then my installation of a SIGBUS
> handler overwrites the libsigsegv handler, and you lose out on stack
> overflow detection.
That might actually happen on *BSD systems. On MacOS X, this bug will not
happen, because libsigsegv installs a Mach exception handler. This handler
installed by libsigsegv will be invoked before the SIGBUS handler installed
by m4 will be invoked.
> Also, if we modify the c-stack contract to always take care of SIGBUS, is
> there a way to make it detect whether libsigsegv installed a SIBGUS handler?
You can detect it by calling sigaction(SIGBUS,NULL,&curr_handler).
Bruno
