[Bug 189] ash behaves strangely on CTRL-C (does not exit but fills process table)

bugzilla at busybox.net bugzilla at busybox.net
Thu Mar 19 16:30:04 UTC 2009


https://bugs.busybox.net/show_bug.cgi?id=189





--- Comment #12 from Denys Vlasenko <vda.linux at googlemail.com>  2009-03-19 16:30:03 UTC ---
dowait(0x0) called

-- SIGUSR1 & SIGINT --

wait returns pid=-1, status=0x85f1420
token word handler
pipeline: entered
reread token word handler
reread token word handler
reread token word handler
token end of file 
reread token end of file 
reread token end of file 
reread token end of file 
pid 1232, evaltree(0x85f0afc: 0, 0) called
evalcommand(0x85f0afc, 0) called
evalcommand arg: handler
dowait(0x1) called
wait returns pid=0, status=0x0
pid 1232, evaltree(0x85f15ec: 0, 0) called
evalcommand(0x85f15ec, 0) called
evalcommand arg: return
evalcommand arg: 0
dowait(0x1) called
wait returns pid=0, status=0x0
token end of file

up to here it looks more or less ok, SIGUSR1 handler was executed
when dowait() reported EINTR. I guess here:

blocking_wait_with_raise_on_sig(struct job *job)
{
        pid_t pid = dowait(DOWAIT_BLOCK, job);
        if (pid <= 0 && pendingsig)
                raise_exception(EXSIG);
        return pid;
}

But now I'm confused:

pid 1232, evaltree(0x85f0a2c: 4, 2) called
makejob(1) returns %2
forkshell(%2, 0x85f0a2c, 0) called
In parent shell: child = 1239

It does not seem to notice that intpending is set!

Can you expand the tracing? Add   " s:%d i:%d\n", ..., pendingsig, intpending
to these TRACE statements so that we can see whetehr those are set:
        TRACE(("dowait(0x%x) called\n", wait_flags));
        TRACE(("wait returns pid=%d, status=0x%x\n", pid, status));

ALso, can you test we can trigger this bug on simpler script? Running (true) in
subshell is complication trace needlessly.
Try this one:

trap "echo USR1" USR1
while true; do
    echo Sleeping
    sleep 1
done

Thanks for helping with debugging.


-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


More information about the busybox-cvs mailing list