Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -D_FORTIFY_SOURCE=2 -g
-O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -Wall
uname output: Linux fuz.su 3.10.9-xxxx-grs-ipv6-64 #1 SMP Wed Aug 21 11:51:59
CEST 2013 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.3
Patch Level: 11
Release Status: release
Description:
When an unreasonable low limit for the number of executable
processes (e.g. 2) is configured for bash, the shell enters an
infinite loop trying to fork, but either the call to fork()
fails with EAGAIN or a call to wait4() fails with ECHILD every
time, causing bash to enter an infinite loop. bash is then no
longer responsive to interrupts, either from the keyboard or
from outside and can only be killed by issueing a SIGKILL.
I believe but have not tested that this issue can also appear
when the system cannot create new processes for other reasons.
Repeat-By:
In an instance of bash, type ulimit -n 2.
Fix:
I am not a bash developer, so my suggestion is probably not the
right thing to do. Anyway, bashbug(1) asks for a suggestion on
how to fix the encountered issue so here it is.
Fix the way bash blocks the delivery of signals when it can't
fork so keyboard interrupts or signals received otherwise still
have a way to get through. Stop trying to fork after some
attempts and provide a reasonable emergency code-path for the
case that bash cannot fork.
