latest from CVS segfaults when FD ulimit is set too low

[Jim Meyering <jim@xxxxxxxxxxxx>]

Hello,

I was surprised to see zsh segfault.
I confirmed that it happens also with the latest from CVS.
Here's a nearly minimal reproducer (same with ulimit -n 12):

  $ printf '_src_etc_profile_d() { f=; }\n_src_etc_profile_d\n' > k
  $ Src/zsh -f -c '( . ./k; ulimit -n 7 && exec 0</dev/null )'
  zsh:1: cannot duplicate fd 0: invalid argument
  zsh: segmentation fault  Src/zsh -f ...

Note that this is not contrived.
It is derived from real code in coreutils' test suite that
exercises GNU sort, attempting to verify that it performs
even under extreme FD pressure.  Because zsh treats the first
10 FDs specially, that makes that particular test fail, so now
we just skip it when zsh happens to be the shell used by the test.

Also, note that the above does not segfault every time.
For me, on Fedora 11 and x86_64, it segfaults approximately 8 in 10 times.

Rerunning under valgrind:

==20742== Memcheck, a memory error detector.
==20742== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==20742== Using LibVEX rev 1884, a library for dynamic binary translation.
==20742== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==20742== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==20742== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==20742== For more details, rerun with: -v
==20742==
==20742== Warning: invalid file descriptor 12 in syscall fcntl(DUPFD)()
zsh:1: cannot duplicate fd 0: too many open files
==20742== Invalid read of size 4
==20742==    at 0x42B593: closemnodes (exec.c:1907)
==20742==    by 0x42B7A5: addfd (exec.c:1983)
==20742==    by 0x42E43C: execcmd (exec.c:2872)
==20742==    by 0x42A758: execpline2 (exec.c:1579)
==20742==    by 0x4298EA: execpline (exec.c:1364)
==20742==    by 0x428FA8: execlist (exec.c:1161)
==20742==    by 0x42F39A: execcmd (exec.c:3170)
==20742==    by 0x42A758: execpline2 (exec.c:1579)
==20742==    by 0x4298EA: execpline (exec.c:1364)
==20742==    by 0x428FA8: execlist (exec.c:1161)
==20742==    by 0x4289E3: execode (exec.c:988)
==20742==    by 0x42898A: execstring (exec.c:973)
==20742==  Address 0x4c17000 is not stack'd, malloc'd or (recently) free'd
==20742==
==20742== Process terminating with default action of signal 11 (SIGSEGV)
==20742==  Access not within mapped region at address 0x4C17000
==20742==    at 0x42B593: closemnodes (exec.c:1907)
==20742==    by 0x42B7A5: addfd (exec.c:1983)
==20742==    by 0x42E43C: execcmd (exec.c:2872)
==20742==    by 0x42A758: execpline2 (exec.c:1579)
==20742==    by 0x4298EA: execpline (exec.c:1364)
==20742==    by 0x428FA8: execlist (exec.c:1161)
==20742==    by 0x42F39A: execcmd (exec.c:3170)
==20742==    by 0x42A758: execpline2 (exec.c:1579)
==20742==    by 0x4298EA: execpline (exec.c:1364)
==20742==    by 0x428FA8: execlist (exec.c:1161)
==20742==    by 0x4289E3: execode (exec.c:988)
==20742==    by 0x42898A: execstring (exec.c:973)
==20742==  If you believe this happened as a result of a stack overflow in your
==20742==  program's main thread (unlikely but possible), you can try to increase
==20742==  the size of the main thread stack using the --main-stacksize= flag.
==20742==  The main thread stack size used in this run was 10485760.
==20742==
==20742== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 2)
==20742== malloc/free: in use at exit: 48,565 bytes in 925 blocks.
==20742== malloc/free: 1,128 allocs, 203 frees, 89,327 bytes allocated.
==20742== For counts of detected errors, rerun with: -v
==20742== searching for pointers to 925 not-freed blocks.
==20742== checked 276,856 bytes.
==20742==
==20742== LEAK SUMMARY:
==20742==    definitely lost: 0 bytes in 0 blocks.
==20742==      possibly lost: 0 bytes in 0 blocks.
==20742==    still reachable: 48,565 bytes in 925 blocks.
==20742==         suppressed: 0 bytes in 0 blocks.
==20742== Rerun with --leak-check=full to see details of leaked memory.