Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED

Status

()

Core
XUL
--
critical
RESOLVED FIXED
11 years ago
7 years ago

People

(Reporter: Daniel Beckham, Unassigned)

Tracking

({verified1.8.1.1})

1.8 Branch
PowerPC
Mac OS X
verified1.8.1.1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 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.
(Reporter)

Comment 1

11 years ago
Created attachment 243382 [details]
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

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

Updated

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

Comment 3

11 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

11 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

11 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

Comment 6

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

11 years ago
I routinely test (patches on) a build with xul cache and fastload disabled.
Status: UNCONFIRMED → NEW
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.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Comment 10

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

Updated

9 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.