Closed Bug 608738 Opened 14 years ago Closed 11 years ago

Firefox 4 hangs whole system when viewing high resolution .png image (2020x6198)

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: dotnokato, Unassigned)

References

(
URL
)

Details

(Whiteboard: [sg:dos])

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101101 Firefox-4.0/4.0b8pre Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101101 Firefox-4.0/4.0b8pre Firefox 4 causes whole system to stop responding after/while loading of a high-resolution .png file. Reproducible: Always Steps to Reproduce: 1. Open Firefox. 2. Go to: http://www.nibyblog.pl/wp-content/uploads/linua-czasu-gnu-linux.png 3. Wait until it loads. Actual Results: Whole system hangs - stops responding. Have to hard-reboot. Expected Results: Image should load, system shouldn't stop responding.
Version: unspecified → Trunk
The bug doesn't occur on Epiphany Browser.
WFM with a nightly build. This might depend on the amount of memory available. In any case, doesn't need to be security-group-private.
Group: core-security
Product: Firefox → Core
QA Contact: general → general
Whiteboard: [sg:dos]
Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 Same bug with Firefox 3.6.13 on Debian Queeze x86_32 with http://upload.wikimedia.org/wikipedia/commons/e/ed/LinuxDistroTimeline.png Please, affect this issue to Firefox 3.6.13. Xorg freeze (1GB RAM). To reproduce : 1. Goto http://upload.wikimedia.org/wikipedia/commons/e/ed/LinuxDistroTimeline.png 2. On about the middle of the downloading, all freeze. 3. Reboot. 4. Relaunch Firefox, all freeze again. 5. Move the file corresponding at LinuxDistroTimeline.png in cache directory to another directory. 6. Load in Firefox. 7. The system freeze again. Loading this image in a viewer as evince works fine. I have no problem with http://www.nibyblog.pl/wp-content/uploads/linua-czasu-gnu-linux.png
(In reply to comment #3) > I have no problem with > http://www.nibyblog.pl/wp-content/uploads/linua-czasu-gnu-linux.png Yes I have bug : a bad display after reloading with a distorted or empty image.
Workaround : I had in /etc/modprobe.d/radeon-kms.conf, an option for radeon RV100 video driver: modeset=1. This setting accelerates text mode but slow down X mode and, perhaps consumes memory video. So with the default modeset (I deleted /etc/modprobe.d/radeon-kms.conf), now Xorg has now more high speed and now Firefox does not still freeze and works fine. @dotnokato: Have you same setting or too low video memory amount ?
@rpnpif: I do not have this setting. I have 256 MB of video memory and 2GB of system memory. Also, the bug doesn't occur for me while using: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12pre) Gecko/20110210 Firefox/4.0b12pre (latest nightly). Both http://upload.wikimedia.org/wikipedia/commons/e/ed/LinuxDistroTimeline.png and http://www.nibyblog.pl/wp-content/uploads/linua-czasu-gnu-linux.png load just fine.
I have been seeing a variant of this on Windows since FF 3.6 or perhaps earlier. My desktop is a 2ghz Pentium box with 3GB of RAM, using onboard VIA Chrome S3 video. The current monitor is 1280x1024 with 32bit color, though I've run in 1600x1200 in the past. OS is WinXP SP3 with current patches. When viewing sites with large images, FF can hang the entire system, forcing a hard reset to get it back. Image type doesn't seem to matter - I normally see it with JPGs. I just encountered it earlier at Project Gutenberg, in http://www.gutenberg.org/ebooks/19499 (Music Notation and Terminology by Karl Wilson Gehrkens) I'm using the latest Minefield build at the moment. Clicking the HTML link to view the volume on line triggered the crash. No trace gets left in the Windows event log and FF doesn't seem to leave useful traces either, so beyond "trying not to do that", I'm at a loss. Any suggestions as to how to debug this? ______ Dennis
(In reply to comment #7) > I have been seeing a variant of this on Windows since FF 3.6 or perhaps > earlier. > > My desktop is a 2ghz Pentium box with 3GB of RAM, using onboard VIA Chrome S3 > video. The current monitor is 1280x1024 with 32bit color, though I've run in > 1600x1200 in the past. OS is WinXP SP3 with current patches. > > When viewing sites with large images, FF can hang the entire system, forcing a > hard reset to get it back. Image type doesn't seem to matter - I normally see > it with JPGs. > > I just encountered it earlier at Project Gutenberg, in > http://www.gutenberg.org/ebooks/19499 (Music Notation and Terminology by Karl > Wilson Gehrkens) I'm using the latest Minefield build at the moment. > > Clicking the HTML link to view the volume on line triggered the crash. > > No trace gets left in the Windows event log and FF doesn't seem to leave useful > traces either, so beyond "trying not to do that", I'm at a loss. > > Any suggestions as to how to debug this? And it just did it again, in a fresh instance of Minefield, with four tabs open. Sysinternals Process Explorer was running while it loaded, and reported 62.12% CPU usage, 357,704K Private Bytes, 346,904K Working Set, and 702,104K Virtual Storage at the point things hung. Oddly, the Images sub-directory lists a lot of files (http://www.gutenberg.org/files/19499/19499-h/images/) but none of them are all that big. There is also a sub-directory of MIDI files, but I don't believe these should affect anything. Can anyone else reproduce this? I'm willing to believe it's a quirk of my system and XP, but the problem does *not* occur in Google Chrome 10 dev branch, IE 8, Opera 11.01, or Safari 5.0.3. ______ Dennis
Couldn't reproduce with today's nightly build on WinXP. I think those hangs are somehow related to large memory consumption (maybe virtual?), but cannot prove that as for now.
(In reply to comment #9) > Couldn't reproduce with today's nightly build on WinXP. > > I think those hangs are somehow related to large memory consumption (maybe > virtual?), but cannot prove that as for now. I'll see about grabbing a nightly and trying again. I had cautious hopes the problem had been resolved in FF 4.0, and was unpleasantly surprised when it bit again. I'll try with a current SeaMonkey, too, but suspect it's a Gecko thing and will bite there as well. ______ Dennis
(In reply to comment #10) > (In reply to comment #9) > > Couldn't reproduce with today's nightly build on WinXP. > > > > I think those hangs are somehow related to large memory consumption (maybe > > virtual?), but cannot prove that as for now. > > I'll see about grabbing a nightly and trying again. I had cautious hopes the > problem had been resolved in FF 4.0, and was unpleasantly surprised when it bit > again. > > I'll try with a current SeaMonkey, too, but suspect it's a Gecko thing and will > bite there as well. Ahhhh. Just got a new Minefield build, and the problem *didn't* bite using it. That seems to make it an FF issue, and the question is what changed in the new build that might have affected things. As mentioned in my prior post, Minefield wasn't using gobs of RAM at the point it hung the machine. I'd normally think of excessive memory consumption as a culprit, too, but that didn't seem to be the case. ______ Dennis
(In reply to comment #11) > > As mentioned in my prior post, Minefield wasn't using gobs of RAM at the point > it hung the machine. I'd normally think of excessive memory consumption as a > culprit, too, but that didn't seem to be the case. I do not know if memory consumption is the culprit but I think so that this issue exists with big images: This Gutenberg page have big images after decompression of jpeg, it is perhaps why the issue is present. Now, with my workaround, all works fine. Remark: my OS is Linux Debian. I will try a nightly release of Firefox.
I'm experiencing this (or a similar bug) intermittently. Although as well as becoming unresponsive my whole display flickers and my only recourse is to perform a hard shut-down (i.e. hold power button) as the entire system is unresponsive (not simply firefox). Due to the above specifics being thus far absent from this bug report, I'm wondering whether this bug is related or not to my own experiences. I'm running Mozilla Firefox 4.0b12 under Ubuntu 10.10 (x86-64) with nVidia's proprietary GPU drivers (nvidia-current v270.29). Kind Regards, Lee.
(In reply to comment #13) > I'm experiencing this (or a similar bug) intermittently. Although as well as > becoming unresponsive my whole display flickers and my only recourse is to > perform a hard shut-down (i.e. hold power button) as the entire system is > unresponsive (not simply firefox). > > Due to the above specifics being thus far absent from this bug report, I'm > wondering whether this bug is related or not to my own experiences. > > I'm running Mozilla Firefox 4.0b12 under Ubuntu 10.10 (x86-64) with nVidia's > proprietary GPU drivers (nvidia-current v270.29). It just happened to me again, with the most recent Beta13Pre nightly. I was using the Sage extension to browse RSS feeds, and looked at the Dark Roasted Blends blog. (http://www.darkroastedblend.com/) That site tends to have large images, and the problem seems to bite when I attempt to load a page that has them. (I normally see it bite on Project Gutenberg books that contain large images, if I try to preview the book in the browser.) I rebooted and tried again, with Sysinternals Process Explorer monitoring the progress of FF. Memory usage did not spike (it was 300 and some MB,) nor did disk I/O, and CPU usage was about 47% at the time. It just hung hard. When I rebooted and ran Minefield in Safe Mode, and looked at the site directly rather than through the RSS reader, the problem did not occur. No surprise, as the RSS feed attempts to load all images associated with stories, while a direct visit to the site only does so when you click through to read a story. I'd *love* to know what is happening, or have an idea how to debug it. Interesting that is happened to you under Ubuntu 10.10. I thought it might be an XP issue. I have Ubuntu here, but have not tried to reproduce the problem in it. It's currently installed on an old notebook that just doesn't have the horsepower to run a current Linux FF release at all. (<1ghz CPU, 256MB RAM, UDMA 4 HD. FF 3.6 takes 45 seconds just to load, and is perceptibly sluggish when up. To the extent I browse on it, I use Midori.) ______ Dennis
(In reply to comment #14) > It just happened to me again, with the most recent Beta13Pre nightly. I was > using the Sage extension to browse RSS feeds, and looked at the Dark Roasted > Blends blog. (http://www.darkroastedblend.com/) That site tends to have large > images, and the problem seems to bite when I attempt to load a page that has > them. (I normally see it bite on Project Gutenberg books that contain large > images, if I try to preview the book in the browser.) And it happened again, this time going to the mentioned blog site directly, and trying to read the main story on the front page. Lots of large images try to load and *blam*, I'm hung and must hit the reset switch. I had Sysinternals Process Explorer examining the Firefox process, and the Performance tab of the process properties had the following numbers when it hung: CPU Priority 8 Kernel time 0:01:54:182 User time 0:08:30:484 Total time 0:10:125:296 Context 675 Virtual Memory Private Bytes 370,644 KB Peak Private Bytes 594,768 KB Virtual Size 695,776 KB Page Faults 1,056,795 Page Faults Delta 1,490 Physical Memory Memory Priority n/a Working Set 327,968 KB WS Private 302,620 KB WS Shareable 25,384 KB WS Shared 9,720 KB Peak Working Set 1,490 I/O I/O Priority n/a Reads 157, 524 KB Read Delta 193 Read Bytes Delta 181.2 KB Writes 52,057 Write Delta 46 Write Bytes Delta 661.1 KB Other 161,132 Other Delta 163 Handles Handles 560 Peak Handles n/a GDI Handles 1,326 User Handles 35 These don't look unreasonable to me, but I'm not certain what they *should* look like. I do know I wasn't seeing significant RAM use, disk I/O, or CPU load. It just hung, badly enough to require a reset to get the system back. ______ Dennis
After about one month of usage with the workaround of comment #5, this bug never happens again for me on Debian 6.0 with Firefox 3.6 or 4.0b12. All big images load smoothly.
I did not experience any problems on the pages cited above in Firefox 26b2, this has probably been fixed in the meantime, so WFM. If anybody still has any of these issues, feel free to reopen. Please make sure that you have the latest graphics driver versions installed, and test against a recent Nightly[1]. [1] http://nightly.mozilla.org/
Severity: critical → normal
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.