142853 - disabling XUL cache causes assertions, eats ram

Status: VERIFIED FIXED

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

Description

[Morten Nilsen]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

To ben, ccing other fastload culprits...

Comment 2

[John Morrison]

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?

Comment 3

[Mike Shaver (:shaver emeritus)]

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.

Comment 4

[rossi]

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.

Comment 5

[Chris Waterson]

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'?

Comment 6

[timeless]

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 7

[timeless]

Attachment: check the pref before getting the service

Comment 8

[Alec Flett]

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.

Comment 9

[timeless]

.

Comment 10

[Chris Waterson]

Comment on attachment 83385 [details] [diff] [review]
check the pref before getting the service

r=waterson

Comment 11

[timeless]

Comment on attachment 83385 [details] [diff] [review]
check the pref before getting the service

checked in

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

isn't this fixed now?

Comment 13

[rossi]

yes it does, disabling xul cache works fine again.

Comment 14

[timeless]

i was waiting for confirmation that i solved the leaks, i got it from people.

fixed :-)

Comment 15

[Hixie (not reading bugmail)]

v based on comments