322886 - browser appears to spend all idle time re-drawing GIFs that don't exist

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Phil Schwan]

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

At first I thought this might be a dupe of bug 322232, but my stack doesn't have any obvious connection to plugins.  Only a few more data points will reveal the truth, I think.

I find after a day or three of browsing that an idle firefox will consume 40-60% of my Powerbook G4's CPU.

Enough was enough, I said, egged on by shaver, and installed Shark.  The results are relatively unambiguous.  This is the stack that is responsible for the first 40%:

	0.0%	46.8%	firefox-bin	start	
	0.0%	46.8%	firefox-bin	nsAppStartup::Run()	
	0.0%	46.8%	firefox-bin	nsAppShell::Run()	
	0.0%	46.8%	firefox-bin	nsMacMessagePump::DoMessagePump()	
	0.0%	46.8%	firefox-bin	nsMacMessagePump::GetEvent(EventRecord&)	
	0.0%	46.8%	HIToolbox	WaitNextEvent	
	0.0%	46.8%	HIToolbox	WNEInternal	
	0.0%	46.7%	HIToolbox	GetNextEventMatchingMask	
	0.0%	46.2%	HIToolbox	RunCurrentEventLoopInMode	
	0.0%	45.9%	CoreFoundation	CFRunLoopRunSpecific	
	0.1%	43.6%	CoreFoundation	__CFRunLoopRun	
	0.0%	42.6%	CoreFoundation	__CFRunLoopDoSources0	
	0.0%	42.3%	libxpcom_core.dylib	PL_ProcessPendingEvents	
	0.0%	42.1%	libxpcom_core.dylib	PL_HandleEvent	
	0.0%	42.0%	libxpcom_core.dylib	handleTimerEvent(TimerEventType*)	
	0.0%	41.8%	libxpcom_core.dylib	nsTimerImpl::Fire()	
	0.0%	41.3%	firefox-bin	imgContainerGIF::Notify(nsITimer*)	
	0.1%	41.0%	firefox-bin	imgContainerGIF::DoComposite(gfxIImageFrame**, nsRect*, gfxIImageFrame*, gfxIImageFrame*, int)	
	0.0%	39.9%	firefox-bin	gfxImageFrame::DrawTo(gfxIImageFrame*, int, int, int, int)	
        ... more inner frames ...

The other 60% is the kernel doing IPC, handling faults, and adjusting mappings.  Related to the non-stop GIF drawing, I assume?  I don't know, you tell me.

To anticipate a few questions:

- No, there are no pages loaded with plugins (or gifs).  In fact, no pages visible of any kind.  Before I gathered the data, I closed all tabs except for one new empty one, pure as the wind-driven snow.

- In three days of heavy use, the browser has probably seen every kind of content imaginable.

- I've been suffering with this for months, but I have not yet detected a pattern to any particular type of content that triggers it.

- Restarting the browser resets the clock, and I get another day or three until I notice that my fan never turns off anymore.

- To make the pain of restarting every three days less acute, I installed SessionSaver.  But this behaviour long predates my use of that plugin.

One stack trace is not maximally useful, but I'll add more Shark data until it becomes clear that there is a trend, or the bug gets fixed, or Safari gets adblock.  I kept the raw data, but each 30-second snapshot is 1.4 MB.  If someone wants it, I'll attach it, or put it on the web.

I'm sure that someone will figure out in which component this belongs, but maybe only after some analysis.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

I've asked Phil to test disabling fastback, to see if that affects the behaviour.  (It happens to me, too.)

Comment 2

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

With fastback disabled (max_total_viewers at 0), this still happened.

Comment 3

[Adam Guthrie]

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

Comment 4

[buovjaga]

Is this still relevant or has code churn made it obsolete?

Comment 5

[Mark Banner (:standard8)]

I suspect code churn has made it obsolete. It was also filed on Power PC which we no longer support.