bash enters endless loop when under unreasonably low RLIMIT_NPROC

[Robert Clausecker]

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.