[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-hackers] Diagnosis for; How to interpret chicken post mortem?

From: Jörg F . Wittenberger
Subject: [Chicken-hackers] Diagnosis for; How to interpret chicken post mortem?
Date: Sun, 29 Nov 2015 17:55:40 +0100
User-agent: Mozilla/5.0 (X11; Linux armv7l; rv:38.0) Gecko/20100101 Icedove/38.3.0

Am 26.11.2015 um 11:29 schrieb Jörg F. Wittenberger:
> Something is definitely wrong at master and it is non-deterministic.

I found the cause.  The issue pertains to all recent versions of CHICKEN.

To trigger the bug you need to do the following in order:

1. Use set-signal-handler! to establish a signal handler.

2. Use a C library which (silently) creates a pthread.  Now this pthread
inherits the signal handler.  This is all fine normally.  I'd expect
most libraries to be not aware of signal handler which record the stack
pointer somewhere.  Hence libraries might not be careful to block signals.

3. Wait for a signal to be dispatched to the other pthread.  Done.

So the example code from
would be already vulnerable.

The signal handler in the other thread will happily set the global
variable C_stack_limit to point 1000 word off the stack pointer at the
other thread.

This may be even fine sometimes.  As long as the code arrives soon
enough at handle_interrupt it will restore C_stack_limit =
saved_stack_limit.  But if  !handling_interrupts still holds when the
next signal is delivered, saved_stack_limit will be set point into the
stack of the other thread.  That's bad when it is eventually restored.

There are workarounds.  But they are ugly.

I'd suggest to simply register the interrupt in the C handler and handle
*all* interrupts within ##sys#thread-yield!.  This would have the added
benefit that all those calls to ##sys#dispatch-interrupt would become



reply via email to

[Prev in Thread] Current Thread [Next in Thread]