From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-27280-mason-zsh=primenet.com.au@sunsite.dk>
Received: (qmail 16544 invoked from network); 18 Sep 2009 09:48:28 -0000
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.2.5
Received: from new-brage.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.254.104)
  by ns1.primenet.com.au with SMTP; 18 Sep 2009 09:48:28 -0000
Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts)
Received: (qmail 96320 invoked from network); 18 Sep 2009 09:48:24 -0000
Received: from sunsite.dk (130.225.247.90)
  by a.mx.sunsite.dk with SMTP; 18 Sep 2009 09:48:24 -0000
Received: (qmail 27102 invoked by alias); 18 Sep 2009 09:48:21 -0000
Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 27280
Received: (qmail 27073 invoked from network); 18 Sep 2009 09:48:21 -0000
Received: from bifrost.dotsrc.org (130.225.254.106)
  by sunsite.dk with SMTP; 18 Sep 2009 09:48:21 -0000
Received: from mx.meyering.net (mx.meyering.net [82.230.74.64])
	by bifrost.dotsrc.org (Postfix) with ESMTP id 2C0E28026E39
	for <zsh-workers@sunsite.dk>; Fri, 18 Sep 2009 11:48:14 +0200 (CEST)
Received: by rho.meyering.net (Acme Bit-Twister, from userid 1000)
	id 49460130F; Fri, 18 Sep 2009 11:48:13 +0200 (CEST)
From: Jim Meyering <jim@meyering.net>
To: zsh-workers@sunsite.dk
Subject: latest from CVS segfaults when FD ulimit is set too low
Date: Fri, 18 Sep 2009 11:48:13 +0200
Message-ID: <87iqfgwplu.fsf@meyering.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: ClamAV 0.94.2/9814/Thu Sep 17 19:17:50 2009 on bifrost
X-Virus-Status: Clean

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.