Closed Bug 408029 Opened 17 years ago Closed 13 years ago

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

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: steven, Unassigned)

References

(
URL
)

Details

(Whiteboard: [needs retesting on Linux])

Attachments

(1 file)

Crash Log
152.97 KB, application/rtf
Details 
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 (http://earth.imagico.de/5gp/view.php?tile=14A) 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 http://earth.imagico.de/5gp/view.php?tile=14A
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.
Attached file Crash Log — 
Crash log pertaining to the bug.
Is this maybe (minus the crash) another instance of bug 364221?

cl
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.
Sorry about the RFT. This is the log that Mac OS X produced after saying Camino "crashed" so it is all that I have.
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.
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:

http://mms.space.swri.edu/MMSposter-large.jpg
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....
(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).


(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.
Same for me on my iMac at home
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.

2. 
* 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)
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.
Does anyone who sees this behavior not see it in corresponding Minefields builds? If not, then this should be moved to core.
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.
(In reply to comment #18)

It was backed out... see Vlad's bug 412396 comment 30.
I went to fetch a Minefield build with that patch included from
http://hourly-archive.localgho.st/mac.html
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.
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?
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.
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.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
I have not seen this issue occur in the past 2 months. Has anyone else continued to have this occur?
I can slow Camino down pretty bad if I open several tabs of large images and nothing else, but I can't crash it.
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:
http://fawkes1.lpl.arizona.edu/images/gallery/lg_408.jpg

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.
(In reply to comment #26)

> http://fawkes1.lpl.arizona.edu/images/gallery/lg_408.jpg

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.

Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
QA Contact: general → thebes
crash gentoo linux, ubuntu 8.04 too.
Are you guys still hitting these crashes with Ubuntu 9.10 and Firefox 3.5+?  What do the stacks look like nowadays?
Btw, it's likely that any remaining bugs are platform-specific.
Whiteboard: [needs retesting on Linux]
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
2GB RAM
I have reproduced what I believe is this bug in our downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=608259. There is more information and strace (https://bugzilla.redhat.com/attachment.cgi?id=427936) of firefox opening locally downloaded http://upload.wikimedia.org/wikipedia/commons/2/2a/Eta_Carinae_Nebula_1.jpg (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.
Status: NEW → RESOLVED
Closed: 16 years ago → 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: