Re: problem with multios on irix 5.3, zsh 3.0.1

Re: problem with multios on irix 5.3, zsh 3.0.1

[rjones]

hzoli@cs.elte.hu writes:
>It may be the problem.  The lower bound check was missing indeed and it was
>fixed a few weeks ago.  The upeer bound check is not necessary if the
>fdtable is as big as the maximum number of open file descriptors of the OS.
>Try to modify the
>
>#  define OPEN_MAX 20
>
>line in system.c, give it a bigger value (64 or 256) and see if it stops
>the coredump.  The missing lower bound check is of course a bug but it
>cannot cause coredumps or any noticable problems.

i'll try this.  thanks.

on solaris (reported by a friend), where OPEN_MAX was set to the max
for the OS, it still failed silently, only opening the first N files
(N = about 53.  64 is the max).  is this what it should do?

ray jones

Re: problem with multios on irix 5.3, zsh 3.0.1

[Zoltan Hidvegi]

rjones@pobox.com wrote:
> i built zsh 3.0.1 "out-of-the-box", didn't get any compiler errors,
> etc. on an irix 5.3 system.
> 
> i discovered this possible bug:
> 
> in a directory with a large number of files:
> 
> % cat < * > /dev/null
> 
> this gives a seg fault on irix.  on solaris, according to a friend, it
> just stops at the 54th file.  my best guess is that the fdtable is
> filling up.  there don't seem to be any upper-bounds checks in the
> functions in util.c that deal with fdtable.  no lower bound check in
> zclose, either, so sometimes max_zsh_fd can go beyond the end of the
> array or go negative (unless there's some invariant condition that keeps
> it from going negative.  some debugging seemed to indicate that it was
> going neg, though.).

It may be the problem.  The lower bound check was missing indeed and it was
fixed a few weeks ago.  The upeer bound check is not necessary if the
fdtable is as big as the maximum number of open file descriptors of the OS.
Try to modify the

#  define OPEN_MAX 20

line in system.c, give it a bigger value (64 or 256) and see if it stops
the coredump.  The missing lower bound check is of course a bug but it
cannot cause coredumps or any noticable problems.

> fdtable[pipes[!out]] = 2;
> 
> it may be ansi-acceptable to trust "!" to always return 0 or 1, but
> this would probably be easier to read if it were
> 
> fdtable[pipes[out ? 0 : 1]] = 2;

out is always zero or one here.  Here is a piece of code:

        zclose(pipes[out]);
        fdtable[pipes[!out]] = 2;

In that case !out is more clear and it really means the opposite of out.
Writing out ? 1 : 0 produces less efficient machine code.

Zoltan

problem with multios on irix 5.3, zsh 3.0.1

[rjones]

i built zsh 3.0.1 "out-of-the-box", didn't get any compiler errors,
etc. on an irix 5.3 system.

i discovered this possible bug:

in a directory with a large number of files:

% cat < * > /dev/null

this gives a seg fault on irix.  on solaris, according to a friend, it
just stops at the 54th file.  my best guess is that the fdtable is
filling up.  there don't seem to be any upper-bounds checks in the
functions in util.c that deal with fdtable.  no lower bound check in
zclose, either, so sometimes max_zsh_fd can go beyond the end of the
array or go negative (unless there's some invariant condition that keeps
it from going negative.  some debugging seemed to indicate that it was
going neg, though.).

while trying to track down the problem, i also found some code in
exec.c that looks like this:

fdtable[pipes[!out]] = 2;

it may be ansi-acceptable to trust "!" to always return 0 or 1, but
this would probably be easier to read if it were

fdtable[pipes[out ? 0 : 1]] = 2;

that's personal preference, of course.

thanks,
ray jones