bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

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

NEW
Unassigned

Status

()

Firefox
General
13 years ago
2 years ago

People

(Reporter: Phil Schwan, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
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:
I've asked Phil to test disabling fastback, to see if that affects the behaviour.  (It happens to me, too.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
With fastback disabled (max_total_viewers at 0), this still happened.

Comment 3

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

Comment 4

2 years ago
Is this still relevant or has code churn made it obsolete?
You need to log in before you can comment on or make changes to this bug.