Re: gc & blocked signals

On Tue, Jan 31, 2012 at 2:03 PM, Helmut Eller <[email protected]>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
_______________________________________________
cmucl-imp mailing list
[email protected]
http://lists.zs64.net/mailman/listinfo/cmucl-imp