From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: zsh-workers-request@euclid.skiles.gatech.edu Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by coral.primenet.com.au (8.7.5/8.7.3) with ESMTP id FAA24098 for ; Sun, 3 Nov 1996 05:35:56 +1100 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id NAA29724; Sat, 2 Nov 1996 13:18:19 -0500 (EST) Resent-Date: Sat, 2 Nov 1996 13:18:19 -0500 (EST) From: "Bart Schaefer" Message-Id: <961102102158.ZM23264@candle.brasslantern.com> Date: Sat, 2 Nov 1996 10:21:58 -0800 In-Reply-To: "C. v. Stuckrad" "Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (2)" (Nov 2, 4:30pm) References: Reply-To: schaefer@nbn.com X-Mailer: Z-Mail (4.0b.820 20aug96) To: "C. v. Stuckrad" , Zsh workers list Subject: Re: Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (2) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"bbcj91.0.JG7.h1vUo"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2314 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Nov 2, 4:30pm, C. v. Stuckrad wrote: } Subject: Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (2) } } On Sat, 2 Nov 1996, C. v. Stuckrad wrote: } } > Program terminated with signal 11, Segmentation fault. } > #0 0x6fe4c in zclose (fd=19) at utils.c:921 } > 921 while (!fdtable[max_zsh_fd]) } (gdb) p max_zsh_fd } $1 = 16777234 } ^ ^ ^ ^ OUTCH !?!?!?!? } (gdb) p fdtable } $2 = '\000' , "\001\001" } } Well, this explains the coredump, but WHY ? zsh is picking an arbitrary value of 20 for the OPEN_MAX constant. If zclose() is being called on fd=19, chances are that at some previous time the fdtable[] array was overflowed and trampled on max_zsh_fd. Chances are further that the reason for this is that `screen' is leaving way too many file descriptors open when it forks off children. This is actually a potential security problem, because a program written to expect this behavior might obtain access to a pseudo-tty that it was not supposed to be able to access. I seem to recall patching at least one version of `screen' to close down file descriptors when forking children, but that was years ago; I very seldom use `screen' any more since it became gnuware (no, not *because* it did), and I quit hacking on it even before that. As the comment in system.h says, OPEN_MAX should be getting set by doing a query of the OS at run time. You should try to get a fixed screen, but you should also try compiling with a larger OPEN_MAX (around 64 for SunOS, I think) and see if that solves the problem. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern