Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Firefox instantly locks the X server when browsing to url http://upload.wikimedia.org/wikipedia/commons/2/2a/Eta_Carinae_Nebula_1.jpg (for other users it reportedly only hangs up Firefox itself). Version-Release number of selected component (if applicable): How reproducible: 100% (tried two times, works perfectly and instantly) Steps to Reproduce: 1. Open firefox 3.6.4 2. Browse to URL Actual results: X crashes: I get a black screen with a text cursor as if I switched to a TTY, but the text cursor does not blink and X's hardware cursor is still visible (but frozen and may not be moved anymore with the mouse). Any reaction to any sort of keyboard command, e.g. ctrl+alt+f<n> to switch to a TTY, is dead. The ACPI shutdown button works flawlessly, which I guess means that X is dead/crashed but the system itself is just fine. Expected results: Firefox hangs (since it seems to be dealing with such huge images pretty badly) but is not able to instantly kill my X server. Additional info: client glx vendor string: Mesa Project and SGI OpenGL renderer string: Mesa DRI Intel(R) 945GME GEM 20100328 2010Q1 OpenGL version string: 1.4 Mesa 7.8.1 Installed Packages Name : xorg-x11-server-Xorg Arch : i686 Version : 1.8.0 Release : 12.fc13 Size : 3.5 M Repo : installed From repo : anaconda-InstallationRepo-201005130056.i386 Summary : Xorg X server URL : http://www.x.org License : MIT Description: X.org X11 is an open source implementation of the X Window System. : It provides the basic low level functionality which full fledged : graphical user interfaces (GUIs) such as GNOME and KDE are designed : upon. Installed Packages Name : xorg-x11-drv-intel Arch : i686 Version : 2.11.0 Release : 4.fc13 Size : 782 k Repo : installed From repo : anaconda-InstallationRepo-201005130056.i386 Summary : Xorg X11 Intel video driver URL : http://www.x.org License : MIT Description: X.Org X11 Intel video driver.
(In reply to comment #0) > Firefox instantly locks the X server when browsing to url > http://upload.wikimedia.org/wikipedia/commons/2/2a/Eta_Carinae_Nebula_1.jpg > (for other users it reportedly only hangs up Firefox itself). Well, I wouldn't call anything which involves downloading 91.2 MB of data "instant", but yes, I have problems with this image as well. It looks like a duplicate of the referred upstream bug though. Do you get really crash of Xorg (i.e., black screen, console, gdm login screen), or does your computer gets really really really slow? If you press Ctrl-Alt-F2 and wait five minutes (at least) do you get to the console?
Created attachment 427936 [details] product of strace -o /tmp/firefox-strace.txt -f firefox -no-remote -P ~/.mozilla/firefox/vez3gin8.temporary/ Tested with a temporary completely clean profile. First opened this bug and then (via Ctrl-O) was trying to locally downloaded copy of the image.
And yes eog has absolutely no problem with the image (its dimensions are 14321x29566 points)
and yes switching between X and console (Ctrl-Alt-F2) took couple of minutes.
We believe that it is more appropriate to let it be resolved upstream. We will continue to track the issue in the centralized upstream bug tracker, and will review any bug fixes that become available for consideration in future updates. Thank you for the bug report.
I think some here got the bug report a bit wrong. Everyone commenting here seems to hint the 'usual', known behaviour of Firefox to cause a huge hang, eat a lot of memory and generally just cause hassle with such a big image. This is *not* the issue I attempted to describe with this bug report! Instead, as soon as Firefox tries to display the very first pixel line here (this does NOT involve downloading the whole image at all, it happens right away) the X server locks *totally* and *irreversibly* up. I get a black screen, the X server is *dead*, this is not at all the usual slowdown which still allows switching to the TTY after a few minutes of delay and causes a lot of CPU and disk rattling. This is an instant death with absolutely no sign of any activity afterwards. I also filed this upstream, but filed this bug here additionally because I figured this doesn't appear to be Firefox related to me: To me, this seems to be an X/video driver issue since Firefox apparently easily shoots X instantly down due to some sort of package/request which X causes to instantly die. If you aren't completely sure Firefox really should be able to cause this instant death of X then I really advice to reopen this bug.
> or does your computer gets > really really really slow? If you press Ctrl-Alt-F2 and wait five minutes (at > least) do you get to the console? To make it absolutely clear: No, this happens on machines where X works correctly - here, this is really an instant, complete death of X with instant black screen and X is gone which I assume is some bug of either X or the intel driver.
Created attachment 429358 [details] Log of the hangup
Created attachment 429361 [details] Reproducing/demonstrating the bug step 1 of 4 Step 1/4: I click on the link with middle mouse button (opens in a background tab)
Created attachment 429362 [details] Reproducing/demonstrating the bug step 2 of 4 Step 2/4: I move the mouse over the tab. The image is already loading there, still everything fine.
Created attachment 429363 [details] Reproducing/demonstrating the bug step 3 of 4 Step 3/4: I clicked on the tab to switch there. This happens *instantly*: black screen, mouse remains at same position, frozen text cursor, mouse/keyboard everything dead. No disk rattling or loudly spinning fan, the computer is just sitting quiet and X is dead.
Created attachment 429364 [details] Reproducing/demonstrating the bug step 4 of 4 Step 4/4: Any key combinations to attempt to switch to a TTY don't work. The only thing left to do is pressing the power button to shut down (which works like a charm WITHOUT doing a hard reset, it properly shuts down and the system/kernel is apparently not locked up)
I reopen this bug now, also see the photos I attached for reproduction (I think they show pretty well that this is not the usual firefox hanging issue but instead an Xorg crash). If that is an entirely bad thing to do I apologize, but that seems to be the right thing to do to me.
OK, if it is crash in Xorg, then please add drm.debug=0x04 to the kernel command line, restart computer, and attach (you could try to get to the computer via ssh?): * your X server config file (/etc/X11/xorg.conf, if available), * fresh X server log file (/var/log/Xorg.*.log) * output of the dmesg command, and * system log (/var/log/messages) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. For further information on Xserver debugging see http://wiki.x.org/wiki/DebuggingTheXserver We will review this issue again once you've had a chance to attach this information. Thanks in advance.
The X server log is already attached (if the .old one I fetched after reboot is indeed the one before the reboot, that is, when it crashed). Sadly it doesn't seem to output anything helpful I believe, when reading the http://www.spinics.net/lists/xorg/msg50093.html changelog of intel 2.12 here, that those bugfixes they did in regards of huge images and screen corruption might be related to my issues. Testing with other large images that aren't that huge but still huge, I get interesting results: I also get heavy screen corruption downright to a complete X hang (not crash) if I use smaller images (something around 4000x4000) instead of that huge one I linked with this bug report. It's pretty interesting that eye of gnome can display those 4000x4000 images without any issues, this only happens with firefox (does it use some other way of displaying images?). Maybe I should test intel 2.12 as soon as it becomes available to see whether it fixes this crash and the corruption issues for me. I will fetch the remaining files (dmesg, syslog and those) in the next 24 hours if SSH'ing still works (which I assume)
xorg-x11-drv-intel 2.12.0 resolves those issues completely (only the firefox hangup due to excessive overload remains as usual)! Pretty annoying that 2.11's handling of large image is so incredibly broken. Do you still require the crash logs then?
Thank you for letting us know.
*** Bug 614592 has been marked as a duplicate of this bug. ***
This bug is CLOSED CURRENTRELEASE but the current one is xorg-x11-drv-intel-2.11.0-5.fc13 even if for about a month there is indeed available in koji xorg-x11-drv-intel-2.12.0-1.fc13; only is it not released. Should not this be reopened?
BTW - an attemtp to get in firexof http://upload.wikimedia.org/wikipedia/commons/2/2a/Eta_Carinae_Nebula_1.jpg on the current F13 installation with intel video resulted in an immediate message from firefox that "this image cannot be displayed as it contains errors" so an attempt to reproduce came to naught. I bumped into this report while searching for something related to a display crash during an upgrade in anaconda. In the middle of package installation a display crashed with the following in syslog: 22:52:53,674 ERR kernel:[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung 22:52:53,691 ERR kernel:render error detected, EIR: 0x00000000 22:52:53,698 ERR kernel:[drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 7366 at 7364) Only that (luckily for me) anaconda continued "in blind" and eventually finished, and I have no idea which driver version was in use (kernel 2.6.33.3-85.fc13.i686) and so far I have not seen similar in a desktop use.