Possible race in bash signal handling?

[CliffordWolf]

Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: gcc-34
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-unknown-linux-gnu' 
-DCONF_VENDOR='unknown' -DSHELL -DHAVE_CONFIG_H  -I.  -I. -I./include -I./lib  
-g -O2
uname output: Linux murphy 2.6.12.3-rock #1 SMP Sun Aug 7 15:13:36 CEST 2005 
i686 unknown unknown GNU/Linux
Machine Type: i386-unknown-linux-gnu

Bash Version: 2.05b
Patch Level: 0
Release Status: release

Description:
        One of my bash scripts got killed with a sig11. I was curious so I
        made a stack backtrace:

                (gdb) bt
                #0  0x0806da71 in kill_current_pipeline ()
                #1  0x0806eb6a in kill_pid ()
                #2  0x0806efd1 in kill_pid ()
                #3  <signal handler called>
                #4  0x4007d6f6 in free () from /lib/libc.so.6
                #5  0x0806d7cc in save_pipeline ()
                #6  0x0806d816 in cleanup_the_pipeline ()
                #7  0xbfed2dac in ?? ()
                #8  0x0807351f in command_substitute ()
                #9  0x0807351f in command_substitute ()
                ...

        My bash has the following patches applied:

                
http://www.rocklinux.net/svn/rock-linux/trunk/package/base/bash/bash2/

        Is it possible that there is a race condition when a certain signal
        (maybe SIGCHLD? - I'm not sure how to figure out the cought signal
        from stack frame 3) is interrupting the cleanup_the_pipeline()
        codepath?

Repeat-By:
        I'd guess that would be pretty hard reproduce. It happened to me
        while executing a script that never showed this problem before. It
        is a more sophisticated script thought:

                http://www.rocklinux.net/svn/rock-linux/trunk/scripts/Download
                
        The last output seen on the terminal was produced by the

                echo "bzip'ing + cksum-test: $gzfile"

        in line 529 in download_file() called by all() (line 933). There
        are a lot of pipes, command substitutes and '<( .. )' constructs
        in the script. But I'm afraid that the script won't help you much
        tracing the issue..

-- 
L I N : B I T           ___
 _______ __ _____  ____|_  |  The OSS cluster synchronization tool for
/ __(_-</ // / _ \/ __/ __/   configuration files an application images
\__/___/\_, /_//_/\__/____/   --- [ http://oss.linbit.com/csync2/ ] ---
       /___/
 
"You can now flame me, I am full of love, and will ignore any insults,
because that is how good my Gnus filter is." -- MiguelDeIcaza