357852 - nglayout.debug.disable_xul_cache causes Firefox to use 100% of the CPU

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Daniel Beckham]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

In Firefox 2.0, using the debug preference nglayout.debug.disable_xul_cache to turn off XUL caching causes Firefox to consume 100% of the CPU resources on the system if you attempt to open the Downloads, Add Ons or Preferences dialogs.  Additionally, the dialogs never appear.


Reproducible: Always

Steps to Reproduce:
1. Open about:config
2. Create a new boolean preference value named nglayout.debug.disable_xul_cache and set to true.
3. Open either Downloads, Add Ons or Preferences

Actual Results:  
Firefox consumes 100% of the CPU


Please see attached Mac OS X sampler report.

Comment 1

[Daniel Beckham]

Attachment: Mac OS X Sampler tool report with an inverted call graph

I've gzipped the file to overcome the 300K limit to non patch attachments.

Comment 2

[Andreas Wuest]

*** Bug 355247 has been marked as a duplicate of this bug. ***

Comment 3

[Andreas Wuest]

I've run a ktrace and it shows that Firefox is reading from the same two or three
positions in classic.jar and en-US.jar over and over again, without end. See bug #355247 which I've marked as a duplicate of this one.

Comment 4

[timeless]

my guess is that this is basically fastload's fault:

            1 nsFastLoadFileWriter::AddDependency(nsIFile*)
              1 nsFastLoadService::AddDependency(nsIFile*)
                1 nsChromeProtocolHandler::NewChannel(nsIURI*, nsIChannel**)
                  1 nsIOService::NewChannelFromURI(nsIURI*, nsIChannel**)
                    1 MOZ_Z__length_code
                      1 CSSLoaderImpl::LoadSheet(SheetLoadData*, StyleSheetState)
                        1 CSSLoaderImpl::LoadChildSheet(nsICSSStyleSheet*, nsIURI*, nsMediaList*, nsICSSImportRule*)

not that i know who is foolish enough to admit to owning it.

specifically i'm hoping that the css file in question is trying to load a file that doesn't really exist or something which results in some sort of bad recursion. this is very very guessy.

i really wish you didn't have the inverted call graph, although i suspect it wouldn't have helped me much. this is not infinite recursion isn't asynchronous.

Comment 5

[timeless]

this part looks vaguely interesting:

                            14 CSSLoaderImpl::LoadSheet(SheetLoadData*, StyleSheetState)
                              9 CSSLoaderImpl::LoadStyleLink(nsIContent*, nsIURI*, nsSubstring const&, nsSubstring const&, nsIParser*, int&, nsICSSLoaderObserver*)
                                9 XULContentSinkImpl::ProcessStyleLink(nsIContent*, nsString const&, int, nsString const&, nsString const&, nsString const&)
                                  9 XULContentSinkImpl::HandleProcessingInstruction(unsigned short const*, unsigned short const*)
                                    9 nsExpatDriver::HandleProcessingInstruction(unsigned short const*, unsigned short const*)
                                      9 MOZ_XML_GetMismatchedTag
                                        9 MOZ_XML_GetMismatchedTag
                                          9 MOZ_XML_GetMismatchedTag
                                            9 MOZ_XML_Parse
                                              9 nsExpatDriver::ParseBuffer(char const*, unsigned, int)
                                                9 nsExpatDriver::ConsumeToken(nsScanner&, int&)
                                                  9 nsParser::Tokenize(int)
                                                    9 nsParser::ResumeParse(int, int, int)
                                                      9 nsParser::ContinueInterruptedParsing()
                                                        9 CSSLoaderImpl::SheetComplete(SheetLoadData*, int)

it'd be nice to have a debugger break for some of the functions in that snippet.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Looks similar to some issues I recall with the expat position not being updated right, leading to us parsing the same PI over and over again and ending up with the same stylesheet being loaded over and over.  Not sure why the XUL cache affects it, other than that disabling prevents us from synchronously pulling the sheet from said XUL cache and returning it, so we end up blocking the parser where with XUL cache we don't.

Peter, do you happen to have the bug# for the 1.8 branch version of the Expat stuff?

I should note that disabling the XUL cache is basically unsupported and that dynamic overlays (which is what all the windows you mention have in common) have probably never been tested with XUL cache disabled....  So I wouldn't be surprised if this is dynamic-overlay-specific too, in some way.

Comment 7

[[e-mail]]

I routinely test (patches on) a build with xul cache and fastload disabled.

Comment 8

[Mats Palmgren (inactive)]

*** Bug 357777 has been marked as a duplicate of this bug. ***

Comment 9

[Peter Van der Beken [:peterv]]

Should be fixed as part of bug 335047.

Comment 10

[Jay Patel [:jay]]

v.fixed on 1.8.1 branch with 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.1pre) Gecko/20061128 BonEcho/2.0.0.1pre

No unusual CPU usage with steps from comment #0. (Also v.fixed bug 335047)

Daniel:  Can you confirm that the problem you reported has gone away in the latest 1.8.1 nightly builds?  I wonder if this was a general bug or specific to PPC?