Closed
Bug 24828
Opened 25 years ago
Closed 24 years ago
file:*.html + many images -> max_open_files error
Categories
(SeaMonkey :: Build Config, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: roland.mainz, Assigned: cls)
Details
Attachments
(2 files)
1.08 KB,
patch
|
Details | Diff | Splinter Review | |
873 bytes,
patch
|
Details | Diff | Splinter Review |
Testcase: Create 80 images in a local directory, create a HTML document which embeds those images (e.g. <img> tag) with file:// URLs. Mozilla 19. Jan 2000 won't show all images, for some the following error message is displayed: -- snip -- Opening file 17.jpg failed Opening file 16.jpg failed Opening file 15.jpg failed Opening file 14.jpg failed Opening file 13.jpg failed Opening file 12.jpg failed Opening file 11.jpg failed Opening file 10.jpg failed -- snip -- % ulimit -a core file size (blocks) unlimited data seg size (kbytes) unlimited file size (blocks) unlimited open files 64 pipe size (512 bytes) 10 stack size (kbytes) 8192 cpu time (seconds) unlimited max user processes 8197 virtual memory (kbytes) unlimited I think this will happen on all unix machines... IMHO should mozilla check this limit...
C: have you run into this as an issue on X? temporarily reassigning to you, to get it on your radar. -p
Assignee: pnunn → mcafee
Comment 2•25 years ago
|
||
shorter summary, m14.
Summary: When reading a HTML file from disk with a large number of images, Mozilla hits max_open_files → file:*.html + many images -> max_open_files error
Target Milestone: M14
Updated•24 years ago
|
Target Milestone: M16 → M18
Comment 6•24 years ago
|
||
tor just pointed out to me that the default number of file descriptors for Solaris 7 is 64. Ugh! The default number for Solaris 8 is 256. The mozilla script needs to be adjusted to look for the Solaris platform, and if found, do a: ulimit -n 512
While I can't reproduce the running out of descriptors error on demand (mozilla just quietly refuses to load the suggested type of test page), the fix needed is something like the following. A quick inventory of other OS descriptor limits: AIX=2000, Linux=1024, Irix=200. Index: mozilla =================================================================== RCS file: /cvsroot/mozilla/xpfe/bootstrap/mozilla,v retrieving revision 1.8 diff -u -r1.8 mozilla --- mozilla 2000/06/17 00:54:07 1.8 +++ mozilla 2000/07/13 23:42:00 @@ -61,6 +61,11 @@ esac done +# Solaris defaults to 64 descriptors per process. Boost it... +if test `/bin/uname -s` = "SunOS" ; then + /bin/ulimit -n 512 +fi + eval "set -- $moreargs" echo $dist_bin/run-mozilla.sh $script_args $dist_bin/$MOZILLA_BIN "$@" $dist_bin/run-mozilla.sh $script_args $dist_bin/$MOZILLA_BIN "$@"
Comment 9•24 years ago
|
||
Comment 10•24 years ago
|
||
Comment 11•24 years ago
|
||
mcafee, could you review or pass this to someone else? elig is gone, i'm going to try to reset the qacontact.
Assignee | ||
Comment 12•24 years ago
|
||
nsSigHandler.cpp patch has already been checked in. Marking fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 13•24 years ago
|
||
What about setting other limits in the script ? I would vote for a memory limit of 90% (or 1GB) of available memory. This would catch the problems that Mozilla sometimes starts to eat all memory until it hits some other limit (2GB barrier for 32bit apps. !?)...
Comment 14•24 years ago
|
||
verified fixed. Roland - you can file a separate bug on memory limits if you wish.
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 15•24 years ago
|
||
Well, I did not see that problem (that Moz start to eat all available memory it can get) in the last builds... I assume it's gone (hopefully)...
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•