Configuration Information [Automatically generated, do not change]: Machine: powerpc OS: aix5.3.0.0 Compiler: powerpc-ibm-aix5.3.0.0-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='powerpc' -DCONF_OSTYPE='aix5.3.0.0' -DCONF_MACHTYPE='powerpc-ibm-aix5.3.0.0' -DCONF_VENDOR='ibm' -DLOCALEDIR='/tools/haubi/gentoo/sauxz3/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I./include -I. -I./include -I./lib -DDEFAULT_PATH_VALUE='/tools/haubi/gentoo/sauxz3/usr/sbin:/tools/haubi/gentoo/sauxz3/usr/bin:/tools/haubi/gentoo/sauxz3/sbin:/tools/haubi/gentoo/sauxz3/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' -DSTANDARD_UTILS_PATH='/tools/haubi/gentoo/sauxz3/bin:/tools/haubi/gentoo/sauxz3/usr/bin:/tools/haubi/gentoo/sauxz3/sbin:/tools/haubi/gentoo/sauxz3/usr/sbin:/bin:/usr/bin:/sbin:/usr/sbin' -DSYS_BASHRC='/tools/haubi/gentoo/sauxz3/etc/bash/bashrc' -DSYS_BASH_LOGOUT='/tools/haubi/gentoo/sauxz3/etc/bash/bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -I/tools/haubi/gentoo/sauxz3/usr/include -g -O2 uname output: AIX sauxz3 3 5 00000A03D600 Machine Type: powerpc-ibm-aix5.3.0.0
Bash Version: 4.2 Patch Level: 36 Release Status: release Description: On AIX (5.3, 6.1, 7.1), as well as on Interix (any version) I do encounter some race condition in a code similar to: if grep "unwanted" /some/nonexistent/filename then echo "bad" exit 1 fi echo "good" Sometimes it does "bad" while it should do "good" always. As this is part of some large build process, and occurs every once in a while, I've been unable to create a small testcase. However, I've found /very/ similar problem description with Cygwin, even if I don't grok why defining RECYCLES_PIDS shouldn't be enough here: http://www.cygwin.com/ml/cygwin/2004-09/msg00882.html Also, with an older version of libtool, I've had this problem too: http://lists.gnu.org/archive/html/bug-bash/2008-07/msg00117.html While this doesn't happen with more recent libtool any more, I've found an identical problem description with Cygwin again, even if that test script doesn't expose the problem to me: http://sources.redhat.com/ml/cygwin/2002-08/msg00449.html However, here's a rough script to show when PIDs get recycled. --- #! /usr/bin/env bash count=0 min= max= while true do /bin/true & last=$! [[ ${min:=${last}} -gt ${last} ]] && min=${last} [[ ${max:=${last}} -lt ${last} ]] && max=${last} [[ ${#last} > 4 ]] && used=used_${last::((${#last}-4))} || used=used_0 if [[ ${!used} == *" ${last} "* ]]; then break fi (( count+=1 )) eval "${used}+=' ${last} '" if [[ "${count}" == *000 ]]; then echo ${count} fi done echo "reused pid ${last} (min ${min}, max ${max}) after ${count} trials." --- On AIX, this script shows something like: "reused pid 121692 (min 88110, max 121854) after 254 trials." On Interix, this is something like: "reused pid 1805 (min 135, max 2107) after 121 trials." Running this script multiple times in parallel reduces number of trials, especially on Interix. Linux, HP-UX and Solaris need something near 32k trials, depending on how the kernel is configured (Linux: kernel.pid_max). Repeat-By: Unable to repeat in a small testcase, but adding some debug fprintf's to bash's job.c and execute_cmd.c near fork() and waitpid() allowed me to identify pid-recycling as the root problem. Fix: Define RECYCLES_PIDS for AIX and Interix too (like for Cygwin and LynxOS).