[BusyBox 0001280]: [patch] signals never get unblocked (a.k.a wait becomes uninterruptible)

bugs at busybox.net bugs at busybox.net
Wed Mar 21 05:42:58 UTC 2007


The following issue has been SUBMITTED. 
====================================================================== 
http://busybox.net/bugs/view.php?id=1280 
====================================================================== 
Reported By:                johny
Assigned To:                BusyBox
====================================================================== 
Project:                    BusyBox
Issue ID:                   1280
Category:                   Standards Compliance
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     assigned
====================================================================== 
Date Submitted:             03-20-2007 22:42 PDT
Last Modified:              03-20-2007 22:42 PDT
====================================================================== 
Summary:                    [patch] signals never get unblocked (a.k.a wait
becomes uninterruptible)
Description: 
The busybox "ash" shell is signal-challenged, in that it starts ignoring
each
signal after the first delivery. It also double-fires signals under some
circumstances. This patch fixes the first of those issues. I don't have a
fix for the second issue (and not sure if I'll have time to chase that one
down, since it's not actually breaking things in our environment).

Basically what happens is that when a signal gets delivered, the kernel
automatically blocks any further deliveries of that same signal until the
signal handler returns, or the signal mask is explicitly changed. In
busybox,
the signal handler longjmp's to elsewhere. As such, the signal mask keeps
getting added to as signals come in, and stuff breaks more and more. This
isn't
immediately obvious, since the behaviour only appears for busybox
built-in
commands. Commonly things are either executed in a subshell (which then
has the
damage confined to that subshell), or external commands (which don't have
this
issue).

To reproduce, simply run "./busybox ash" (assuming it's built with ash
included of course) and run this sequence:

sleep 10 &
wait
^C
wait
(this might return right away due to the last ^C getting re-fired - bug
http://busybox.net/bugs/view.php?id=2)
wait
^C

As you'll notice, the last ^C has no effect at all, due to SIGINT being
blocked after the first ^C was pressed. With the attached patch, it
behaves as expected. The instant return of the second "wait" is still
present however.

I've run the test case on a 1.1.3 system too, and it too has the same bug.
====================================================================== 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-20-07 22:42  johny          New Issue                                    
03-20-07 22:42  johny          Status                   new => assigned     
03-20-07 22:42  johny          Assigned To               => BusyBox         
03-20-07 22:42  johny          File Added: sigmask.patch                    
======================================================================




More information about the busybox-cvs mailing list