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




13 years ago
9 years ago


(Reporter: dbeckham, Unassigned)



1.8 Branch

Firefox Tracking Flags

(Not tracked)



(1 attachment)



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

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

Comment 2

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


13 years ago
Assignee: nobody → dbaron
Component: General → Style System (CSS)
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch

Comment 3

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

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

13 years ago
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.
Assignee: dbaron → nobody
Component: Style System (CSS) → XP Toolkit/Widgets: XUL
QA Contact: ian → xptoolkit.xul
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.
I routinely test (patches on) a build with xul cache and fastload disabled.
Depends on: 335047
Ever confirmed: true
*** Bug 357777 has been marked as a duplicate of this bug. ***
Should be fixed as part of bug 335047.
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 10

13 years ago
v.fixed on 1.8.1 branch with 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv: Gecko/20061128 BonEcho/

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?
Keywords: verified1.8.1.1


11 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.