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

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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' <repeats 17 times>, "\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