I've just identified a situation in which Mozilla maxes
out the number of open files that is allowed by Mac OS,
and crashes as a result.
Background
It's known that we keep lots of DLLs open while running,
that we never close down (unload) DLLs, and that
autoregistration must, necessarily, open every component
DLL to register it.
Mac OS 8.6 and earlier had a maximum of 384 file control
blocks (FCBs), so it was not possible for more than that
number of files to be open, globally, under that OS. Our
component DLL scheme pushes us close to that limit:
<http://bugzilla.mozilla.org/show_bug.cgi?id=27750>
Users who have lots of fonts intstalled, or run other
FCB-greedy apps, can easily hit that limit.
Mac OS 9 relaxed the FCB limit to 8169 files:
<http://developer.apple.com/technotes/tn/tn1184.html>
In an apparently unrelated problem, the RegXPCOM application
that is used to build the component registry before
shipping (it basically just does an autoreg) was crashing
on Mac:
<http://bugzilla.mozilla.org/show_bug.cgi?id=24312>
The bug
A couple of days ago I diagnosed a bug that caused a
freshly-rebooted machine to crash during autoreg:
<http://bugzilla.mozilla.org/show_bug.cgi?id=64978>
and this appears to be closely related to, if not the
same problem as the RegXPCOM bug mentioned above.
Some debugging in MacsBug strongly suggests that this
bug is caused by us opening lots of files (and keeping
them open), while never yielding any time to the OS. It
appears that during autoreg, we can run out of FCBs even
on Mac OS 9, with dire consequences.
How to fix this? We can yield to the OS during autoreg
(by adding a call to SystemTask() in the autoreg loop),
which avoids the crash. But it also seems that we need
to address some of the underlying problems: that autoreg
doesn't unload the libraries that it just registered (which
has other bad side-effects like hogging memory), and that
we can't get combine DLLs into multi-fragment containers
(as described in bug 27750).
Simon
--
Simon Fraser Entomologist
[EMAIL PROTECTED] http://people.netscape.com/sfraser/