|
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 http://wiki.call-cc.org/eggref/4/concurrent-native-callbacks 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 obsolete. Best /Jerry
[Prev in Thread] | Current Thread | [Next in Thread] |