27.94 KB, application/x-gzip
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.
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.
*** Bug 355247 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
*** Bug 357777 has been marked as a duplicate of this bug. ***
Should be fixed as part of bug 335047.
v.fixed on 1.8.1 branch with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:184.108.40.206pre) Gecko/20061128 BonEcho/220.127.116.11pre 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?