On Tue, Jan 31, 2012 at 2:03 PM, Helmut Eller <heller@common-lisp.net>wrote:
I think there is a problem related to blocked signals and garbage collection:
1. Start cmucl -noinit -eval '(loop (ext:gc :full t))' in a terminal and let it run.
2. Under Linux, cat /proc/<pid>/status shows that SigBlk is 0 i.e. no signals are blocked.
3. Interrupt the loop with C-c (SIGINT) and wait for the debugger.
4. SigBlk is still 0.
5. Type c to continue the loop.
6. SigBlk is now 000000001fc90000
That's a bug, right? It should again be zero.
For your example with just a simple loop, a C-c causes an interrupt to happen right away, so things work. But when GC is running, interrupts are disabled, so the C-c is remembered and and deferred to a later time and then handled with a pendingInterrupt trap. This is the main difference between the two cases. I think the problem is in interrupt_handle_pending: memcpy(&context->uc_sigmask, &pending_mask, NSIG / LONG_BIT); We are trying to restore the sigmask that was saved by setup_pending_signal (that coincidentally copies the entire uc_sigmask to pending_mask). NSIG = 65 and LONG_BIT = 32 on my machine, so memcpy only copies 2 bytes. I think we really want to copy at least 64 bits or 8 bytes. If I modify this code to copy 8 bytes, SigBlk is now 0 after returning, and C-c continues to work. This seems like a very long-standing bug! Thanks for pointing it out. This change will get into the Feb snapshot. I hope you can do some testing with it and let me know how it works out. Ray