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 KAA28285 for ; Mon, 4 Nov 1996 10:23:37 +1100 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id SAA11782; Sun, 3 Nov 1996 18:02:34 -0500 (EST) Resent-Date: Sun, 3 Nov 1996 18:02:34 -0500 (EST) From: Zoltan Hidvegi Message-Id: <199611032125.WAA00362@hzoli.ppp.cs.elte.hu> Subject: Re: Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (FIXED) To: schaefer@nbn.com Date: Sun, 3 Nov 1996 22:25:04 +0100 (MET) Cc: stucki@math.fu-berlin.de, zsh-workers@math.gatech.edu In-Reply-To: <961103104434.ZM27585@candle.brasslantern.com> from Bart Schaefer at "Nov 3, 96 10:44:34 am" X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"0CoQo1.0.zt2.9IIVo"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2320 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu > On Nov 3, 4:37pm, C. v. Stuckrad wrote: > } Subject: Re: Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (FIXED) > } > } OK, setting OPEN_MAX to 64 (and applying Zoltan's fix too) > } did get rid of the bug. > > I'd be curious to know if you tried the two fixes separately. I don't > see how decrementing max_zsh_fd below zero in that loop could possibly > change it to 16777234 ( == (1<<24)+18, which is a lot of decrements); > but taking the bytes in 16777234 as an array of chars (char fdtable[]) > yields "\01\0\0\021" which looks suspiciously like what you'd get if > you started with max_zsh_fd == 18 and stuffed 1 into the first byte. I guess that the problem is that due to the incorrect OPEN_MAX value an fdtable[OPEN_MAX] = 1 assignment happens somewhere. max_zsh_fd comes right after the fdtable array so this assignment overwrites the first byte of max_zsh_fd. On big endian machines like the sparc this causes exactly the described problem. My bugfix has nothing to do with that. That bug I fixed probably can never cause any real problems (it's been there for a while now and noone noticed that) since max_zsh_fd decrements stop at the first non-zero byte and max_zsh_fd is never used for writing. Zoltan