zsh-workers
 help / color / mirror / code / Atom feed
* latest from CVS segfaults when FD ulimit is set too low
@ 2009-09-18  9:48 Jim Meyering
  2009-09-21 20:45 ` Peter Stephenson
  0 siblings, 1 reply; 7+ messages in thread
From: Jim Meyering @ 2009-09-18  9:48 UTC (permalink / raw)
  To: zsh-workers

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.


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2009-09-23 19:41 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-18  9:48 latest from CVS segfaults when FD ulimit is set too low Jim Meyering
2009-09-21 20:45 ` Peter Stephenson
2009-09-22  9:00   ` Peter Stephenson
2009-09-22 13:40     ` Bart Schaefer
2009-09-23 19:40       ` Peter Stephenson
2009-09-22 15:35     ` Wayne Davison
2009-09-22 15:39       ` Peter Stephenson

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).