Large Images Cause High CPU Load and High Memory Usage And Results In Crash




11 years ago
7 years ago


(Reporter: steven, Unassigned)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [needs retesting on Linux], URL)


(1 attachment)



11 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9b2pre) Gecko/2007121100 Camino/2.0a1pre (like Firefox/3.0b2pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9b2pre) Gecko/2007121100 Camino/2.0a1pre (like Firefox/3.0b2pre)

While viewing this website with a large image ( the browser became very slow and scrolling lagged as much as 20-30 seconds. Navigating away from this page did not get rid of the problem and high CPU usage and memory usage remained. After a couple of minutes, the browser finally froze and crashed.

Reproducible: Sometimes

Steps to Reproduce:
1. Open
2. View the images.
3. Scroll around.
Actual Results:  
The browser slowed down to a crawl and lagged for several seconds before responding. High CPU and memory usage resulted in a crash.

Expected Results:  
I expected the browser to view the file with no problem and with little slow down. I also expected the browser to not use anywhere near that much CPU or memory.

Comment 1

11 years ago
Created attachment 292725 [details]
Crash Log

Crash log pertaining to the bug.

Comment 2

11 years ago
Is this maybe (minus the crash) another instance of bug 364221?


Comment 3

11 years ago
This isn't a crash log, it's a spintracer log; if it actually crashed as well, please attach the actual crash log.

When filing bugs in the future, please attach logs as plain text attachments, rather than rtf, so that we don't have to download them to view them.

Comment 4

11 years ago
Sorry about the RFT. This is the log that Mac OS X produced after saying Camino "crashed" so it is all that I have.

Comment 5

11 years ago
If you look in your home folder under Library > Logs > CrashReporter, is there a log from the same time?

When you say scrolling, do you mean actually scrolling, or panning around the image using their controls? Also, you refer to a "large image", is there some way to get a really large image on this page? I can't find anything larger than about 500x500 px.

Comment 6

11 years ago
No, there is not a crash log for Camino from the same time.

What I mean by scrolling is actually using the ball on my Mighty Mouse to move around the entire length of the image.

I cannot find the original image on the URL I posted earlier, but I have found one that causes the same issues:

Comment 7

11 years ago
I don't get any problem on the linked page, or any page on that site.

On the other hand, loading extremely large images can indeed slow down the browser, to the point of making it really unresponsive. Loading the image in comment 6 stopped my Camino (no way to change tabs or do anything but wait till the image has loaded). Once the image is loaded, everything goes back to normal here. All this with my PowerBook G4.
On the other hand, watching Activity Monitor, CPU usage never went above 50%, and real memory usage peaked at 200Mb.

Note that Safari 3 is much worse in this case. Minefield does the same as Camino.
philippe, is there a known Core bug on the "large images loading can make Gecko unresponsive" part?  I'm only familiar with the tiling one....

Comment 9

11 years ago
(In reply to comment #8)

Not that I know, or found. And I've no idea what happens in such a case on faster machines (say, an average Intel IMac).


Comment 10

11 years ago
(In reply to comment #7)

I am running on an Intel MBP and yes, it is slow when loading the image (which to me is somewhat acceptable), however the problem is that Camino continues to be sluggish and unresponsive when the image is fully loaded and no other data is being transferred.

Camino while loading seemed a little sluggish, but otherwise (aide from switching away/back to that tab) seemed fine for me on my MBP.

Comment 12

11 years ago
Same for me on my iMac at home

Comment 13

11 years ago
2 notes I should add:

1. once the image is fully loaded (in a tab), doing anything in the other tabs works perfectly (if anything, it is a little faster in Camino vs Minefield). Zooming in on the image and scrolling works correctly.

* Switching from any tab to the tab containing the image is slow.
* Hiding the browser and switching back is also real slow. That last behaviour does not happen in WebKit and Safari 3.

(and the latest BonEcho build froze solid when loading the image)

Comment 14

11 years ago
On Intel Macs, does it make a difference if you have colour management turned on or off ?
'gfx.color_management.enabled' true
in about:config.

It does not make any difference for me.
But a Windows-only(?) bug 400075, seems to imply some issues with hiding/showing the browser.

Comment 15

11 years ago
Does anyone who sees this behavior not see it in corresponding Minefields builds? If not, then this should be moved to core.

Comment 17

11 years ago
OK.--> Core as Minefield does the same thing.
I checked with the latest Camino (2008012501) on a new low end Intel iMac (1 Gig Ram, 10.5.1)  and a (functional, that is, not mines...) PowerBook G4 (1.5 Gig Ram, 10.4.11).
On both machines: 
* the browser is somewhat non-responsive while the large image loads. But once it is loaded, the browser was fully functional (with a fast net connection).
* Switching back to the tab that contains the large image is somewhat slow (lag before the image is shown, beachball on the ppc machine).
* Hiding/showing the browser is somewhat slow as well (beachball).

The PPC machine was of course much slower (no surprise).

If the image is zoomed in: performance is much better, scrolling through/around the image does not cause problems.

Bug 412396 will possibly improve things here (can't test the patch, as I'm not not set-up to build, atm).
Component: General → GFX: Thebes
Product: Camino → Core
Hardware: Macintosh → All
Version: unspecified → Trunk
We should test this again now that bug 412396 has landed.

Comment 19

11 years ago
(In reply to comment #18)

It was backed out... see Vlad's bug 412396 comment 30.

Comment 20

11 years ago
I went to fetch a Minefield build with that patch included from
I used: 20080127_1745_firefox-3.0b3pre.en-US.mac.dmg, and compared with the 20080127-04 build.

On the Intel iMac/10.5, things seems a little smoother. There is a still a delay when switching to the tab containing the image. Hiding the browser and bringing it back is faster, I think.
On the PPC/10.4 Mac, I'm not so sure. But it is not much worse than what Safari 3 does, except for hiding/showing the browser.

Bear in mind, I had not run Minefield much on the Intel Mac. My perception could be wrong.

Comment 21

11 years ago
I tried loading that image again on my MBP and I did not notice any slowdown at all (although I have upgraded to 4GB of memory since I last tried). I suppose this "bug" has been fixed?

Comment 22

11 years ago
yeah, the browser (on 10.5) remains much more responsive than it ever was. I still noticed a slight delay in bringing Camino forward when it hidden. Could be me, though, the system I'm using is under a bit of heavy load and should have more RAM available.

The improvements are possibly due to bug 414685 (or did 10.5.2 help things ?)..
I don't have access to a 10.4 (ppc) machine, atm, I don't know what happens there.

Comment 23

11 years ago
I hid Camino and brought it back with no slowdown or sluggishness. I have tried everything I know to slow it down or cause slowness, but I cannot get it to do anything and  am not experiencing this "bug" anymore. I am using a 2.4GHz MBP with 4GB of memory.


11 years ago
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME


11 years ago
Resolution: WORKSFORME → ---

Comment 24

11 years ago
I have not seen this issue occur in the past 2 months. Has anyone else continued to have this occur?

Comment 25

11 years ago
I can slow Camino down pretty bad if I open several tabs of large images and nothing else, but I can't crash it.

Comment 26

11 years ago
I can confirm this bug in Firefox3b5 however I cannot install RC1 here so I will have to test that later. I could not get the browser to crash, but I could lock up the system when opening large (>4MB) images such as:

This was on Kubuntu 8.04 with KDE 3.5.9. Other than Firefox (2 tabs), only Amarok (KDE music player) was playing and the music stopped when Firefox locked up. After 40-50 seconds the browser regained consciousness and the music started playing again. This is on a DuoCore 2Ghz machine with 2GB RAM.

Comment 27

11 years ago
(In reply to comment #26)


That on is really big (14173 × 14173 pixels). It locked the browser up here (OS X 10.5.2,both Fx 3RC1 and Camino trunk, Core2duo 2ghz, 2GB), with the image in the active tab. Every action (zoom, scroll) took about 45 ~ 50 secs.

Ever confirmed: true
OS: Mac OS X → All
QA Contact: general → thebes

Comment 28

11 years ago
crash gentoo linux, ubuntu 8.04 too.

Comment 29

9 years ago
Are you guys still hitting these crashes with Ubuntu 9.10 and Firefox 3.5+?  What do the stacks look like nowadays?

Comment 30

9 years ago
Btw, it's likely that any remaining bugs are platform-specific.
Whiteboard: [needs retesting on Linux]

Comment 31

9 years ago
With the image from comment #26 on a clean profile, Firefox just locks up for me. No crash.

Firefox 3.5.6
Kubuntu 9.10
Intel dual-core CPU 2gHz

Comment 32

8 years ago
I have reproduced what I believe is this bug in our downstream bug There is more information and strace ( of firefox opening locally downloaded (14321x29566 points dimensions). Whole computer got almost frozen for couple of minutes even without firefox ever finishing opening of the file.
Filed bug 692781 as for the large image freezing since I can still reproduce it, closing this bug because the original page seems fine and it's gotten quite muddled.
Last Resolved: 11 years ago7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.