Re: Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (FIXED)

["Bart Schaefer" <schaefer@candle.brasslantern.com>]

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.

} BUT, it might be something totally different than I thought, NOT 'screen'
} but 'ssh' (sshd), The secure-shell- programs from Tatu Ylonen
} do open and pass on a filedescriptor to all their descendants.
} 
} This filedescriptor is 'constructed' by a test-program, and seems to
} somehow get a definite number. And I saw this descriptor being the LAST
} POSSIBLE Number (64!).

That shouldn't be a problem, and in fact the reason it shouldn't be one
is *because* it's the last possible descriptor; zsh should never find
out that it exists, because open/dup/etc. should always return the lowest
available descriptor (which should be something between 3 and 63).  The
fdtable[] only includes descriptors that zsh itself has opened.

} So zsh on screen on sshd might have died on that ...

Easy enough to test; run the unpatched zsh under ssh without screen, and
then under screen without ssh.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern