Closed Bug 142853 Opened 22 years ago Closed 22 years ago

disabling XUL cache causes assertions, eats ram

Categories

(Core :: DOM: Core & HTML, defect)

x86
All
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: Morten, Assigned: timeless)

References

(Blocks 1 open bug)

Details

Attachments

(1 obsolete file)

disabling the xul cahce (user_pref("nglayout.debug.disable_xul_cache", true);)
causes these assertions;
###!!! ASSERTION: redundant multiplexed document?: 'docMapEntry->mString ==
nsnull', file ../../../mozilla/xpcom/io/nsFastLoadFile.cpp, line 1338
###!!! Break: at file ../../../mozilla/xpcom/io/nsFastLoadFile.cpp, line 1338
###!!! ASSERTION: unknown aURI passed to EndMuxedDocument!:
'uriMapEntry->mDocMapEntry', file ../../../mozilla/xpcom/io/nsFastLoadFile.cpp,
line 1501
###!!! Break: at file ../../../mozilla/xpcom/io/nsFastLoadFile.cpp, line 1501

these assertions in turn seem to cause some serious leaks.
when I start mozilla with the xul cache disabled, the ram usage quickly rises to
217MB
enabling XUL cache, makes mozilla consume a mere 57MB after some use on my system.
To ben, ccing other fastload culprits...
Assignee: dougt → ben
Is it perhaps time to just disable this pref and rip out any code that 
supported running without a XUL cache? Is there a particular value in 
maintaining this ability?
Disabling the XUL cache is very useful for developers of XUL applications, as
they would otherwise have to restart Mozilla every time they made a change.  I
think we need to revive it.
if you develop a xul application and have to restart mozilla every time you make
a small change and want to see that change... you get mad.
Don't use a debug build, you won't get assertions. Release your code with the
cache turned on, you won't leak. Why exactly is this `critical'?
Blocker         Blocks development and/or testing work 
Critical        crashes, loss of data, severe memory leak 

You're right, the criteria for Blocker are much more fitting.

Some of us do development both inside and outside of chrome and need to be able 
to use this feature. The issue is not releasing chrome, it's developing it.  It 
is not unusual for a chrome developer to crash in c++ land and need to be able 
to interact with debug features. -- I tend to get 30+ at a time, and the 
results were so bad that they disturbed a neighbor in another cube.

In my case, when i enabled xulcache, mozilla wouldn't start (i could load 
profilemanager, but clicking start mozilla resulted in zero windows). -- I'll 
file a bug for this later.
Comment on attachment 83385 [details] [diff] [review]
check the pref before getting the service

this shouldn't be in the XPCOM component

sr=alecf but waterson should r= this.
Attachment #83385 - Flags: superreview+
.
Assignee: ben → timeless
Component: XPCOM → DOM Mozilla Extensions
QA Contact: scc → lchiang
Comment on attachment 83385 [details] [diff] [review]
check the pref before getting the service

r=waterson
Attachment #83385 - Flags: review+
Comment on attachment 83385 [details] [diff] [review]
check the pref before getting the service

checked in
Attachment #83385 - Attachment is obsolete: true
yes it does, disabling xul cache works fine again.
i was waiting for confirmation that i solved the leaks, i got it from people.

fixed :-)
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
QA Contact: lchiang → ian
v based on comments
Status: RESOLVED → VERIFIED
Component: DOM: Mozilla Extensions → DOM
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: