365653 - high cpu load, caused by thread in function jpeg_free_large

Status: RESOLVED WORKSFORME

(Core :: Graphics: ImageLib, defect)

Description

[xrmb]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

On 3 of my computers I can reproduce the problem. 700mhz P3, 512mb, win xp, all patches, newest FF and 2.8Ghz P4, 2gb ram, win2k, all patches.

I never close FF, just minimize it when done surfing. After a while I can see that my P3 runs at ~80% load, and the P4 runs at ~30% load. Its always FF, which has no page open, just an empty tab.

In process-explorer -> process details I can see that a FF thread firefox.exe!jpeg_free_large+0x2a97 is causing the load.

I can exit FF w/o problems.

Reproducible: Always

Steps to Reproduce:
1. open FF
2. go the a page with many images like engadget.com
3. close the tab, wait (sometimes it takes hours)
Actual Results:  
high cpu load

Expected Results:  
no cpu load

Comment 1

[Andras]

i was able to reproduce this bug on my computer. (same os, same ff version)

to be honest i could almost always experience this behavior when using a firefox session for a long time (days) with the machine hibernated and waked up several times.

Comment 3

[Pavel Gutsa]

I filed 367787 which is marked as a duplicate of this bug.
While I think that the root cause of this problem may be the same, the problems are actually different.
In the situation I describe this thread is completely stalling the processor.
This thread is generally exposes abnormal behavior as it is too active.
As I wrote this it occupies 10% of CPU (which you can account as 20% since I have 2 CPU) with no apparent reason for that.
See the attached screenshot

Comment 4

[Pavel Gutsa]

Attachment: FF state when it is not stalled yet but expresses abnormal activity

Comment 5

[Pavel Gutsa]

Now if I leave it open for a while (usually happens overnight) this thread completely stalls the processor.  See attached.

Comment 6

[Pavel Gutsa]

Attachment: Stall

Comment 7

[Pavel Gutsa]

This problem is described in a dozen of threads at forums.mozillazine.org where user are desperately trying to get somebody's attention to this problem.
Here is one for example http://forums.mozillazine.org/viewtopic.php?t=505192&start=15&sid=e0d8eb8b89fd7a216e1511b072e4cc06

It seems like there is a bug somewhere in interrupts handling routines, also I guess you probably know that you've got to limit yourself on actions when you are on DPC IRQL level...

I did some lookup in Google and it seems like you guys are not alone:
http://www.experts-exchange.com/Operating_Systems/Q_22018021.html
http://www.cygwin.com/ml/cygwin/2006-08/msg00305.html
http://forum.utorrent.com/viewtopic.php?id=7416&p=5
http://permalink.gmane.org/gmane.os.cygwin/80740

And you'd probably want to check the following resources:
http://www.osronline.com/showThread.cfm?link=46797
http://www.tutorials-blog.com/nt/ownership-unused/
http://www.codecomments.com/archive421-2005-8-577905.html
http://www.codecomments.com/archive421-2006-5-912175.html
http://www.koders.com/?s=kiunexpectedinterrupt&la=*&li=*

I wonder if it is related to 2 processor configuration, you may not have checked everything carefully, the synchronization is a little more difficult in multiprocessor configuration.
If I understand it correctly, cygwin for example does not support it at all, it runs on single processor in multiprocessor configuration...  So may be setting a process affinity mask would be a valid temporary workaround for the problem.  Just speculating...

Meanwhile i wish you guys a whole lot of good luck and revert to 1.5.9 to see whether it has the same problem on multiprocessor configuration.

Comment 8

[Juergen Stein]

For me this happens on single core cpu's w/o hyperthreading (P3 700mhz, P4 2.8). interesting thing is that it always uses 10-20%, not 100%... it's smart wasting resources ;)

Comment 9

[Pavel Gutsa]

Attachment: New stall thread stack

Yes, it uses 10-20 constantly, but eventually gets to 100 and is not coming back...
Here is a new screenshot, stack trace is related to memory allocation again...

Comment 10

[Pavel Gutsa]

I'd say this bug should be critical, not normal...

Comment 11

[Ken True]

I have the same issue with high cpu load with jpeg_free_large+0x24a97 being the thread consuming the cpu.
P4/2GHz, 1GB RAM, Win-XP-Pro SP2 with current patches.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

It doesn't happen right away, but after some browsing around, CPU gradually goes to 100% with Firefox the chief consumer of cycles.

I agree, it shouldn't be a 'normal' bug but high severity at least.

I can kill Firefox with process explorer, and resume the sessions with out the high CPU.  Sure is a pain though.

Comment 12

[Pavel Gutsa]

I confirm that this doesn't happen to me anymore since I switched back to 1.5.0.9
Although it uses the jpeg_fdct_low routine from JFIF instead.
Come on guys, mark the VistaFox as betha, put the 1.5.0.9 download back on the front page...

Comment 13

[Rocky Morgan]

XRMB mentions Engadget.  I get this issue quite regularly subscribing to engadget via BlogLines usually if I leave my computer on o/night.  BL uses AJAX to dynamically refresh.  Maybe....?

My computer is configured to standby after 15mins.

Comment 14

[Ken True]

I'd heard on a weather forum that the high CPU may be caused by the ForecastFox add-on.

I disabled ForecastFox 0.9.3.1 and ForecastFox Enhanced 0.9.3.1 yesterday, and haven't had a cpu problem with FF 2.0.0.1

Maybe it's not a FireFox problem, but a ForecastFox problem...

Ken

Comment 15

[Juergen Stein]

I think I can confirm what Ken True says. On two of my computers I've the problem, they both have ForecastFox. On the other two w/o ForecastFox I never saw the problem.

I'll disable the plugin for now and update... lets see what happens in the next 2 days.

Comment 16

[Rocky Morgan]

Definetly fixed it for me.  Thank Ken.  Appols for not being more thorough before posting

Comment 17

[Ken True]

I'd suffered the problem for quite a while before searching bugzilla and finding this thread, so no apology is needed .. I'm just glad I mentioned it on another forum and had a reply to disable the ForecastFox.  Now if we can just get ForecastFox to fix the problem it is causing, I'll re-enable it.

Ken

Comment 18

[Ryan Grange]

Windows XP SP2, 1GB Ram, 2.0 GHz single CPU / single core.
Firefox 2.0.0.1

I uninstalled Firefox, deleted the Mozilla directory from my Application Data, restarted the system, and reinstalled Firefox 2.0.0.1 with feedback and DOM inspector.  Installed absolutely no add-on extensions.  High CPU usage from jpeg_free_large after browsing about 5 web pages (including the default Google search page).

CPU usage drops after several minutes, but I can't take 5 minute breaks every 20 minutes at work.  The fact that I'm having to post this from Internet Explorer just so I can get through it without wanting to mash my keyboard speaks volumes beyond this bug report.

This behavior started in just this past week.  Prior to that, I had no problems with FF 2.x using ForcastFox, Web Developer, FasterFox, Sage, Color Picker, StumbleUpon, Adblock Plus, and UserAgent Switcher.

Using Process Explorer to determine the thread at fault like so many others have.  Until I saw that, I thought it was the upgrade to Sun's new JRE6.  Installing the same upgrade at home did *not* affect my home system's performance.

Comment 19

[Paul J. Ste. Marie]

I'm getting the same thing of FF 2.0.0.6 on WinXP Pro SP2, 2 Gb RAN, Intel Core 2 CPU.

Typically appears when 20+ tabs are open.  Clean reinstall with no extensions didn't help, neither does disabling Flash.

Comment 20

[Paul J. Ste. Marie]

The URL <http://support.microsoft.com/kb/176347> is triggering this fairly consistently.

Comment 21

[Wayne Mery (:wsmwk)]

xrmb and friends,
Is this still seen when using FF3?
Do you see it even with flashblock installed and with it blocking flash images?

Comment 22

[Paul J. Ste. Marie]

Early versions of FF3 had the problem, but I haven't seen it in v3.0.1

Comment 23

[Pavel Gutsa]

I've never seen this problem after I upgraded to FF3.
My current version is 3.0.3 
I load it quite heavily with a lot of open windows and a lot of open tabs in the windows - no problems noticed.

Comment 24

[Wayne Mery (:wsmwk)]

=> WFM then.  Thanks for the update.