Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: unlimited file descripters causes problems for zsh-4.0.2
- X-seq: zsh-workers 16086
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Matthew Braun <matthew@xxxxxxx>, zsh-workers@xxxxxxxxxx
- Subject: Re: unlimited file descripters causes problems for zsh-4.0.2
- Date: Fri, 19 Oct 2001 16:40:41 +0000
- In-reply-to: <200110182344.TAA12655@xxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <200110182344.TAA12655@xxxxxxxxxxxxxxxxxxxxxx>
On Oct 18, 7:44pm, Matthew Braun wrote:
}
} caused by zsh-4.0.2 doing an memory alloc for the max number of file
} descriptors, which in this case is (2^32)-1 (2GB).
[...]
} 1. Change the code back to "fdtable_size = OPEN_MAX;"
} problem I see: fascist
The only time anything is weritten into fdtable, the code first checks
whether it needs to make it larger, so this is hardly "facist". It was
probably a bad idea to use zopenmax() in that context in the first place.
What I'm more concerned about is closeallelse() in exec.c, which is going
to make up to several billion close() calls (plus a lot of unnecessary
looping) every time a process with a redirection is started; but which I
think could be caused to leak descriptors if it doesn't scan all the way
to the actual maximum fd.
} One thing I did notice was the global int "max_zsh_fd" is never
} initialized before first using its value. It appears we are currently
} counting on it being automatically initialized to zero (by the compiler
} or linker). This variable should get initialized in the code I assume.
No, it's perfectly valid to assume that the compiler will initialize a
variable to zero. That's required by all definitions of the C language.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
Messages sorted by:
Reverse Date,
Date,
Thread,
Author