file:*.html + many images -> max_open_files error

VERIFIED FIXED

Status

P3
major
VERIFIED FIXED
19 years ago
14 years ago

People

(Reporter: roland.mainz, Assigned: cls)

Tracking

Trunk
All
Solaris

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
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...

Comment 1

19 years ago
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

19 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

Comment 3

19 years ago
m15
Target Milestone: M14 → M15

Comment 4

19 years ago
Move to M16 for now ...
Target Milestone: M15 → M16

Updated

19 years ago
Target Milestone: M16 → M18

Comment 5

19 years ago
Move to M21 target milestone.
Target Milestone: M18 → M21

Comment 6

19 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

Comment 7

19 years ago
Changing the component to Build/Config.
Component: ImageLib → Build Config

Comment 8

19 years ago
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

19 years ago
Created attachment 12183 [details] [diff] [review]
Patch to boost file descriptors on Solaris

Updated

19 years ago
Keywords: patch

Comment 10

19 years ago
Created attachment 12719 [details] [diff] [review]
Moved fix to nsSigHandlers.cpp per vidur

Comment 11

19 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: mcafee → cls
Keywords: review
QA Contact: elig → granrose
(Assignee)

Comment 12

18 years ago
nsSigHandler.cpp patch has already been checked in.  Marking fixed.

Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 13

18 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

18 years ago
verified fixed.

Roland - you can file a separate bug on memory limits if you wish.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 15

18 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)...
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.