Firefox can't handle 20mb jpeg from wikipedia.org

[Hans Harhoff Andersen]

Binary package hint: firefox-3.0

When opening:
WARNING MAY CRASH BROWSER: http://upload.wikimedia.org/wikipedia/commons/8/8f/Whole_world_-_land_and_oceans_12000.jpg WARNING
from this page :
http://en.wikipedia.org/wiki/Image:Whole_world_-_land_and_oceans_12000.jpg
Firefox tries to open it but chokes about 20% through and becomes unresponsive; taking up over a 1GB of ram/swap. That in turns makes the system virtually useless. I tried downloading the image and displaying it in eog. eog also had trouble opening the picture but did way better than Firefox. Opening the picture after it has been downloaded made Firefox able to open the picture and display it but FF became unresponsive. I waited about 10 minutes before killing it.

If it is an impossible task to open this picture then FF should warn before attempting; else it should give an option save the state of Firefox just before so that all the other tabs aren't lost.

ProblemType: Bug
Architecture: i386
Date: Wed Oct 15 23:14:32 2008
DistroRelease: Ubuntu 8.04
NonfreeKernelModules: nvidia
Package: firefox-3.0 3.0.3+build1+nobinonly-0ubuntu0.8.04.1
PackageArchitecture: i386
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=da_DK.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.24-21-generic i686

[Pavlov (pavlov)]

Created an attachment (id=49728)
8001x8001 pixel sized "Hello world" PNG crashes

[Pavlov (pavlov)]

Some kind of fix for this is needed.. if its just a hard limit (for now) we
should probably do it. I will look into this.

[Pavlov (pavlov)]

This loads (very very very slowly) for me on Win2k. I havn't tried anywhere
else yet. The lockup on win2k you are seeing is probably video driver or
memory related.

I'm running on a 1Ghz P3 with 256mb ram (HP Omnibook 6000).

[Pavlov (pavlov)]

Looking at talkback incident 35342053 (linux) doesn't tell me much...

Stack Signature libc.so.6 + 0x1ed41 (0x4043fd41) d1bc3b49

Platform ID LinuxIntel
Trigger Reason SIGIOT: Abort or IOT Instruction: (signal 6)
Stack Trace
libc.so.6 + 0x1ed41 (0x4043fd41)
libc.so.6 + 0x200d8 (0x404410d8)
libstdc++-libc6.1-1.so.2 + 0x2ee55 (0x40544e55)
libstdc++-libc6.1-1.so.2 + 0x2ee72 (0x40544e72)
libstdc++-libc6.1-1.so.2 + 0x2f75b (0x4054575b)
libstdc++-libc6.1-1.so.2 + 0x313c5 (0x405473c5)
nsImageGTK::Init()
gfxImageFrame::Init()
info_callback()
png_push_have_info()
...

I expect this is being caused by the call to |new|, but I am unsure why,
unless, perhaps, it is trying to throw an exception.. It should just be
returning NULL I would think. Of course we don't check for that, but nothing
in nsImageGTK::Init does anything with this memory.

[Pavlov (pavlov)]

Created an attachment (id=49730)
Check for NULL returns from the calls to 'new'

[Pavlov (pavlov)]

(From update of attachment 49730)
er, typo

[Pavlov (pavlov)]

Created an attachment (id=49731)
Check for NULL returns from 'new'

[Pavlov (pavlov)]

While I don't actually think this patch will fix the crash that is being seen
on Linux, it should help some.

[Pavlov (pavlov)]

marking nsbranch-. Most people arn't going to try and load huge images, and
this doesn't happen everywhere. Will try to get to it for 0.9.5 though.

[Pavlov (pavlov)]

.

[Netdragon (netdragon)]

Hi Stuart. :-)

That image worked fine for me although it bogged down my system. Build
2001121608 - Windows XP. Funny thing is, at the same time, I'm Flattening a 1+
GB image in Photoshop. I thought I'd test that image out in Mozilla and watch it
crash. In the middle of that I felt like going to look for a bug on this and
found yours. I can't believe I didn't try this back in around late 2000 when I
did the extremely large Iframe crashes Mozilla thing. I was thinking about it.

I've been making the image for an hour now. Its a 20000x20000 RGB gradient image.

The thing I'm thinking is "How large is too large?".

Shouldn't Mozilla draw the line somewhere?

I was thinking that Libpr0n could pick a certain size - depending on the system
- that it would store in memory. After that, it should say: "Forget it" or
something.

For instance, if you have only 1GB hard drive left and 20MB mem, you aren't
going to be able to load a 1.2GB image. To try would be futile.

There are several options (maybe you can think of others):

1. Not load the image.
2. After a certain size, Mozilla could start to degrade image quality (i.e. zoom
out the image and store it at the new zoomed size to remove some of the image
information). A message could be passed to the user that Mozilla did this. The
chance a user would have a monitor big enough to see it in pure quality is
small. In the future, when this is possible - memory is low.

If just low on memory but has enough hard drive space:
3. Only show the part of the image that is in the window at one time. This might
require breaking up the image as it is passed from the decoder. Store the rest
in "scrap files". Does Mozilla currently do this?

I'll be back later when the files are finished. It has been an hour and a half now.

[Netdragon (netdragon)]

Here are the images I was talking about (Might not always be up):
http://mozilla.netdemonz.com/src/patchandtest/100250%20-%20large%20images/

[Mcafee (mcafee)]

the hello world image takes a long time to load on a 450MHz linux box,
eventually it worked but not before galeon sucked down 197M of ram.

[Netdragon (netdragon)]

Photoshop uses a scratch disk for extremely large images. It would be nice if
Mozilla could do something like that. It could even compress an image into
blocks to store it in mem/disk. Each block would contain part of the image, and
compress individually so you don't have to decompress the whole image at once.

See also bug 122581

[Jaimejr (jaimejr)]

nominating ...

what are the chances this is gonna make 099?

[Jaimejr (jaimejr)]

Removing nsbeta1 nomination because this bug has been plussed.

[Netdragon (netdragon)]

Url changed to
http://mozilla.netdemonz.com/src/projects/patchandtest/100250%20-%20large%20images/

[Pavlov (pavlov)]

not easily reproducible; reassessing this for nsbeta1 as minus (gagan from
pavlov's desk)

[Olivier Cahagne (wolruf)]

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

[Olivier Cahagne (wolruf)]

From bug 148060, there's a reproducible testcase with URL
http://user.tninet.se/~yff510t/slike/wtc_satelite.jpg which crashes Mozilla
1.0RC3 on Linux (only ? I didn't crash with Win2k + trunk).
OS -> All (was: Win2k) although this last testcase seems to crash Linux only.

[Brant (brant)]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity. Only changing open bugs to
minimize unnecessary spam. Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

[Dbeattie (dbeattie)]

I noticed behavior like this on build 2002121215 of Mozilla 1.3a, on the
following image:

http://www.oqo.com/_images/H.jpg

It's a 4577 x 3597 pixel image, 1.2 megabytes in disk size. I found this out
from Internet Explorer 5.0 after Mozilla 1.3a froze up trying to load it.
Internet Explorer 5.0 loads the image quickly (assuming a fast Internet
connection) decompresses it completely into memory, taking about 20 MB of memory
to do so, and succeeds in displaying it. Some time after decompressing the
image, IE 5.0 seems to be able to release the memory even while keeping the
image in the browser Window, reallocating it when necessary to decompress on the
fly.

Mozilla, on the other hand, just froze up within a few seconds of clicking on
the link to load the image. I tried this several times... there were a few
instances where if I could get Mozilla to respond to the mouse click to close
the window, everything would come back and the program would keep operating as
normal. Mostly, I tended to give up and force Mozilla out of memory via "End
Task". I believe I was seeing the upper-left-hand corner of the image in the
Mozilla window appearing probably about a minute after beginning to load the
page;... I cannot be sure however, since I was unable to scroll the page to see
any more of the image. Perhaps as much as 30 extra megabytes... I can't say for
sure though whether it was more extra memory than IE 5.0 allocated at its peak
allocation though.

Operating System on my machine is Windows 2000.

I'm not sure whether this information correctly applies to this bug, or to bug
#9922, so I'm cross-posting this information to both bug reports.

Thanks in advance for looking at it.

--David

[Netdragon (netdragon)]

David: How much system RAM do you have? (That's the most important thing to
know, IMHO).

[Davidpjames (davidpjames)]

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

[Felix Miata (mrmazda)]

Loading URL in comment 22 in 20030622 vacpp OS/2 1.4 latest while free RAM was
~28MB reduced free RAM to 512K. On restarting Mozilla with far more free RAM,
loading that image reduced free RAM by 50MB.

[Torstenvl (torstenvl)]

I tried loading a large image
(http://homepages.wmich.edu/~j2ockert/LTValentine.jpg) in Firefox and my machine
became totally unresponsive. Verified in Mozilla Application Suite 1.6. This
should be fixed.

For images/other files over 2MB or whatever, perhaps it would be better not to
handle it in the browser -- the user can then use an external viewer directly,
or save it to disk first. All modern operating systems come with decent image
viewers. Also, I assume that the image isn't redrawn directly from the image
format every time -- the JPEG is probably translated into a bitmap structure of
some sort and then certain pixels are picked out. Since drawing from JPEG each
time might be too slow, and would reduce modularity (all further functions only
need operate on the the bitmap structure, regardless of the format of the image
file), perhaps the best option would be to create a bitmap structure only big
enough for the resized image. This could make redrawing when resizing the window
really slow, but that's not really an issue -- it's far better than it is right
now anyway, and I don't think people who are viewing such a large image are
expecting interruption-free browsing; after all, 3MB JPEGs don't go on web
pages, for the most part. Another option, perhaps better, would be to create a
bitmap structure only as big as the screen resolution. Then that can be scaled
to the window size. This has the added benefit of not affecting the redraw time
of images that are well-handled now. It should be relatively simple:

newDimnsnX = (imgDimnsnX > scrnDimnsnX)?scrnDimnsnX:imageDimnsnX;
newDimnsnY = (imgDimnsnY > scrnDimnsnY)?scrnDimnsnY:imageDimnsnY;
...
scaledImage = malloc( newDimnsnY * newDimnsnX *
                      (colorBitDepth/8 + ((colorBitDepth % 8)==0)?0:1) );

Thanks for your time. :-)

[Torstenvl (torstenvl)]

Oops. That doesn't keep it proportional. But the changes are trivial. &c.

[Ajschult (ajschult)]

see also bug 166862

[Rontilby (rontilby)]

Testcase WFM using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060526 Minefield/3.0a1 ID:2006052604

[Mcafee (mcafee)]

Ronald, which testcase? there's lots of dead links here.

THe 8001x8001 worksforme,
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

My machine has 2.5GB ram, we probably should test this on a low ram machine.

[Felix Miata (mrmazda)]

attachment 49728 WFM with 1.5.0.3 on Linux w/ 512M RAM

[Vseerror (vseerror)]

does it still crash MAC?
attachment 49728 is only testcase that's still available.

w2k - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060421 Minefield/3.0a1
XP - Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060531 Minefield/3.0a1

kills machine performance, slow but no crash
painfully slow on w2k 512MB machine - especially if image is reloaded a few times, it causes windows message "virtual memory will be increased"

not so bad on XP 1GB machine

* SM not slow (2-13 sec) and doesn't kill machine Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0

[Mcafee (mcafee)]

attachment 49728 loads fine in about 2 secs for me, I'm on a 4x2.5GHz ppc a fairly
fast machine, 2.5G ram.

[Mcafee (mcafee)]

I have an intel mac at home, it takes slightly longer to load
attachment 49728 but loads fine in about 4 secs, 4-5 reloads ok,
no crashes, this looks ok to me.

[Vseerror (vseerror)]

something is still a problem. As reported in comment 32 initial load is OK, but reload kills the UI for 20-30 or more secs, but at *low CPU*. It does grab a bunch of memory, maybe it's the memory activity that is affecting UI. tessed on a faster 3.2ghz and current trunk.

you may have to play to make it happen. make sure you do a reload or two. roughly what I did...
load image
zoom in (click on image)
scroll with arrow keys
zoom out
zoom in
reload with shift+ctrl+R
repeat if needed

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007072417 Minefield/3.0a7pre

[Hans Harhoff Andersen (hansharhoff)]

Binary package hint: firefox-3.0

When opening:
http://upload.wikimedia.org/wikipedia/commons/8/8f/Whole_world_-_land_and_oceans_12000.jpg from this page:
http://en.wikipedia.org/wiki/Image:Whole_world_-_land_and_oceans_12000.jpg
Firefox tries to open it but chokes about 20% through and becomes unresponsive; taking up over a 1GB of ram/swap. That in turns makes the system virtually useless. I tried downloading the image and displaying it in eog. eog also had trouble opening the picture but did way better than Firefox. Opening the picture after it has been downloaded made Firefox able to open the picture and display it but FF became unresponsive. I waited about 10 minutes before killing it.

If it is an impossible task to open this picture then FF should warn before attempting; else it should give an option save the state of Firefox just before so that all the other tabs aren't lost.

ProblemType: Bug
Architecture: i386
Date: Wed Oct 15 23:14:32 2008
DistroRelease: Ubuntu 8.04
NonfreeKernelModules: nvidia
Package: firefox-3.0 3.0.3+build1+nobinonly-0ubuntu0.8.04.1
PackageArchitecture: i386
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=da_DK.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.24-21-generic i686

[Philanthropist (phil-benn)]

Tested this on my system (latest Ibex all updates amd64 2GB ram)

It runs fine for a while, and then suddenly starts consuming vast amounts of swap and very heavy I/O. I captured both stages with 'top', see below. At one point it used all but 30MB of my 1GB swap partition. I retrieved about 70% of the image before it stalled.

The tab has been closed for 5 minutes or so now, but the swap hasn't been released. The third 'top' output is from just now, firefox still open but image tab closed.

Hope this helps the diagnosis.

top - 22:29:52 up 17 min, 2 users, load average: 1.17, 0.93, 0.60
Tasks: 128 total, 2 running, 126 sleeping, 0 stopped, 0 zombie
Cpu(s): 16.3%us, 33.2%sy, 0.0%ni, 47.5%id, 2.5%wa, 0.3%hi, 0.2%si, 0.0%st
Mem: 1926708k total, 1118660k used, 808048k free, 352k buffers
Swap: 995988k total, 29364k used, 966624k free, 59864k cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 5492 root 20 0 1877m 181m 9.8m R 83 9.7 4:07.97 Xorg
 7359 user 20 0 1621m 571m 24m S 14 30.4 1:18.14 firefox
  206 root 15 -5 0 0 0 S 1 0.0 0:01.00 kswapd0
 5342 user 20 0 20052 1176 992 S 1 0.1 0:00.42 hald-addon-stor
 5940 user 20 0 130m 9804 7536 S 1 0.5 0:02.42 metacity
 7732 user 20 0 269m 25m 12m S 1 1.4 0:01.30 gnome-terminal

top - 22:37:05 up 24 min, 3 users, load average: 1.90, 1.68, 1.06
Tasks: 130 total, 2 running, 128 sleeping, 0 stopped, 0 zombie
Cpu(s): 4.4%us, 6.6%sy, 0.0%ni, 47.9%id, 40.6%wa, 0.2%hi, 0.3%si, 0.0%st
Mem: 1926708k total, 881992k used, 1044716k free, 284k buffers
Swap: 995988k total, 544180k used, 451808k free, 21056k cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 5492 root 20 0 2053m 87m 5944 S 14 4.7 6:47.79 Xorg
 7359 user 20 0 1621m 588m 4948 R 6 31.3 1:54.51 firefox
 7732 user 20 0 270m 10m 5624 S 3 0.5 0:05.82 gnome-terminal
 5949 user 20 0 286m 7244 3480 S 1 0.4 0:06.60 gnome-panel
 5970 user 20 0 191m 800 472 S 1 0.0 0:01.60 gnome-screensav
 7755 user 20 0 19100 700 452 R 1 0.0 0:02.76 top
    1 root 20 0 5240 180 180 S 0 0.0 0:01.56 init
    2 root 15 -5 0 0 0 S 0 0.0 0:00.02 kthreadd

top - 22:54:57 up 42 min, 2 users, load average: 0.35, 0.77, 1.06
Tasks: 129 total, 1 running, 128 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.6%us, 0.8%sy, 0.0%ni, 97.4%id, 0.0%wa, 0.2%hi, 0.0%si, 0.0%st
Mem: 1926708k total, 806836k used, 1119872k free, 1440k buffers
Swap: 995988k total, 675432k used, 320556k free, 44352k cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 7359 user 20 0 1635m 493m 12m S 4 26.2 2:49.97 firefox
 5492 root 20 0 332m 22m 6440 S 1 1.2 8:35.49 Xorg
 7732 user 20 0 270m 5564 3068 S 1 0.3 0:0...

[Connor Imes (ckimes)]

Confirmed! Freezes up firefox, chews up available RAM and then starts using up swap space. Even massively slowed down the computer.

connor@compy686:~$ uname -a
Linux compy686 2.6.24-20-generic #1 SMP Mon Jul 28 13:49:52 UTC 2008 i686 GNU/Linux

connor@compy686:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 8.04.1
Release: 8.04
Codename: hardy

connor@compy686:~$ apt-cache policy firefox
firefox:
  Installed: 3.0.3+build1+nobinonly-0ubuntu0.8.04.1
  Candidate: 3.0.3+build1+nobinonly-0ubuntu0.8.04.1
  Version table:
 *** 3.0.3+build1+nobinonly-0ubuntu0.8.04.1 0
        500 http://ubuntu.media.mit.edu hardy-updates/main Packages
        500 http://security.ubuntu.com hardy-security/main Packages
        100 /var/lib/dpkg/status
     3.0~b5+nobinonly-0ubuntu3 0
        500 http://ubuntu.media.mit.edu hardy/main Packages

[Hans Harhoff Andersen (hansharhoff)]

I think that it will keep the swap used until Firefox is closed since
there is no reason the discard the data before another programs needs
the swap.
ie. if you press ctrl+shift+t it will open up the tab again. I am
guessing that is why it is still using the memory, but I don't really
know

[Alexander Sack (asac)]

i think there is a bug for this in bugzilla.mozilla.org already. if you have a minute try to find it and let us know.

[sebek (sebeeek)]

It's probably the same as :
https://bugzilla.mozilla.org/show_bug.cgi?id=100250
Can someone confirm?

[Alexander Sack (asac)]

thanks for digging this out. linking to upstream bug (https://bugzilla.mozilla.org/show_bug.cgi?id=100250) accordingly. continue discussion over there.

[Rnicoletto (rnicoletto)]

WFM.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4) Gecko/20090427 Shiretoko/3.5b4

[NoBugs! (luke32j)]

Completely freezes up ubuntu 9.04, Firefox 3.0.10.

[Jruderman (jruderman)]

Many large-image crash bugs have been fixed since this bug was filed. If anyone is still seeing problems, please file a new bug for the specific image and OS.

[madbiologist (me-again)]

Is this still occurring on Ubuntu 10.10 "Maverick Meerkat"? What about on Ubuntu 11.04 "Natty Narwhal"?

[NoBugs! (luke32j)]

Still happening in 12.10 64-bit, Firefox 18.0.2

[dino99 (9d9)]

That version is no more supported