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?
