bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Job-handling bug in bash-3.0 and bash-2.05b


From: Tim Waugh
Subject: Job-handling bug in bash-3.0 and bash-2.05b
Date: Thu, 27 Jan 2005 13:33:07 +0000
User-agent: Mutt/1.4.1i

Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: i386-redhat-linux-gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' 
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H  -I.  -I. -I./include -I./lib  -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -O2 -g -pipe -D_FORTIFY_SOURCE=2 -m32 -march=i386 
-mtune=pentium4
uname output: Linux gene.surrey.redhat.com 2.6.9-1.667 #1 Tue Nov 2 14:41:25 
EST 2004 i686 i686 i386 GNU/Linux
Machine Type: i386-redhat-linux-gnu

Bash Version: 3.0
Patch Level: 16
Release Status: release

Description:
        Original bug report:
          https://bugzilla.redhat.com/buzgilla/show_bug.cgi?id=145124

        When bash has been running long enough for child processes to
        start getting PIDs that have been used before by bash child
        processes, bash seems to get confused.

Repeat-By:
        Attached is a gzipped tar file containing a test case.  It
        might take an hour or two to show the problem, at which time
        it will print a message and stop.

        It runs a loop, monitoring PIDs of child processes, and then
        causes PIDs to wrap by executing lots of commands until it
        spots that the newly created PIDs are about to overlap with
        the PID range used in the first instance.

        The way it knows that the bug has been triggered is by
        watching the exit code of this command:

        grep -q foo /dev/null

        It knows that it will always exit with code 1 (and strace
        output shows that it is indeed doing so), but sometimes $?
        contains 0 instead.  When this happens, the grep process has
        invariably been a recycled PID, i.e. one that bash has
        forked before (and which had exited with code 0).

        I can provide strace output to show this occurring, if you are
        unable to reproduce the problem yourself.

Fix:
        I wish I knew.  Perhaps when bash forks a new process it
        should scan its jobs[] array and remove any stale jobs having
        the same PID.

Tim.
*/

Attachment: pgp8VoLfHoyWp.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]