Re: Severe Bash Bug with Arrays

[Greg Wooledge]

On Wed, Apr 25, 2012 at 01:31:11PM -0400, Chet Ramey wrote:
> OK.  Maybe someone with OpenBSD can debug the appropriate code in
> execute_cmd.c:execute_pipeline.  Maybe the call to move_to_high_fd
> fails.

Breakpoint 1 at 0x41d5fc: file execute_cmd.c, line 2107.
Breakpoint 2 at 0x414aa3: file general.c, line 444.
(gdb) run ~/foo
...
Breakpoint 1, execute_pipeline (command=0x202665680, asynchronous=0,
    pipe_in=-1, pipe_out=-1, fds_to_close=0x20e5bd660) at execute_cmd.c:2107
2107      BLOCK_CHILD (set, oset);
(gdb) cont
Continuing.

Breakpoint 2, move_to_high_fd (fd=0, check_new=0, maxfd=255) at general.c:444
444       if (maxfd < 20)
(gdb) n
453         nfds = maxfd;
(gdb) n
455       for (nfds--; check_new && nfds > 3; nfds--)
(gdb) n
459       if (nfds > 3 && fd != nfds && (script_fd = dup2 (fd, nfds)) != -1)
(gdb) n
468       return (fd);
(gdb) print fd
$1 = 0
(gdb) n
469     }

Is that saying it's searching for an available file descriptor starting
at or near 255?

cyclops:/var/tmp/bash/bash-4.2$ ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) 524288
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) 2631052
max memory size         (kbytes, -m) 7888636
open files                      (-n) 128
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 4096
cpu time               (seconds, -t) unlimited
max user processes              (-u) 128
virtual memory          (kbytes, -v) 528384

That's the OpenBSD box.  The HP-UX box is even more extreme:

$ ulimit -a
core file size          (blocks, -c) 2097151
data seg size           (kbytes, -d) 65536
file size               (blocks, -f) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 60
pipe size            (512 bytes, -p) 16
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 76
virtual memory          (kbytes, -v) unlimited

Maybe it only works on boxes with a very large "open files" resource
limit.  Perhaps the hard-coded 255 should be replaced with something
involving getrlimit() or similar?