Created attachment 56237 [details] Backtrace from core file Hello, X crashes for me when I try to display a huge image (8000x8000 px) in eog or iceweasel. The same image works fine in both Opera and geeqie. After the crash, I get back to the login screen. Other running X screens on the same computer (Thinkpad T410s) are not disturbed, but the crash also occurs with only one running instance. I already filed this bug at Debian (cf. http://bugs.debian.org/657634 and http://bugs.debian.org/646393). The bug occurs with xserver-xorg-core version 2:1.11.3.901-2 and 2:1.11.99.901-1 with xserver-xorg-video-intel version 2:2.17.0-1 and 2:2.17.0+git20120115-1 respectively. libdrm-intel1 has version 2.4.30-1 (all Debian package version numbers). The bug occurs on stock Debian kernels 3.2-amd64 as well as on customly compiled kernels only containing the most important modules. Judging from the other bug report on Debian, it already existed for Linux 3.0-amd64. I am not able to test other architectures than amd64. My hardware is a Core i5 520M with integrated graphics, presenting itself in lspci as: 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) I attached the corresponding log file and a backtrace produced with the earlier version (1.11.3.901 and 2.17.0-1 of the packages mentioned above). If there is anything else with which I can help, please do not hesitate to point out how :)
Created attachment 56238 [details] Log file of the crash
That should have been fixed with commit 735219cd59e6184a6622d3d429a704ca3f58b9cd Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Dec 2 10:42:00 2011 +0000 uxa: Ensure that we can fallback with all of (src, mask, dst) as GTT mapping Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> commit 85d3dc5910a2eea3a10b822e01443e11eaae9291 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Dec 2 10:22:51 2011 +0000 uxa: Reset size limits based on AGP size The basis for the constraints are what we can map into the aperture for direct writing with the CPU, so use the size of the mappable region as opposed to the size of the total GTT. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> which is not 2.17.0-1 but should have been in 2:2.17.0+git20120115-1, but iiui 2.17.0+git20120115 is from experimental which should have had SNA enabled and never had this problem...
Created attachment 56239 [details] xorg.conf
As I said, I also tested with the versions from experimental with a stock Debian kernel. I have to admit, though, that the behaviour changed slightly: For Iceweasel/Firefox, just opening the image (http://farm8.staticflickr.com/7151/6760135001_14c59a1490_o_d.jpg) crashed X However, for eog, opening the image by itself did not crash X. X crashed when I maximized the previously about 500x500 pixels large window of eog to approx. 1420x900 pixels. I don’t know what SNA is or should do, but I attached my xorg.conf in case it interfered badly with SNA.
Can you also attach a log / backtrace from the experimental version of the driver?
Hah, I recognise that image as the same one I've been testing all week following bug 45235.
Created attachment 56240 [details] Backtrace, new versions from Debian experimental, maximising eog This is a backtrace from a core file created by these versions of Debian packages: ii xserver-xorg 1:7.6+10 X.Org X server ii xserver-xorg-core 2:1.11.99.901-1 Xorg X server - core server ii xserver-xorg-core-dbg 2:1.11.99.901-1 Xorg - the X.Org X server (debugging symbols) ii xserver-xorg-input-all 1:7.6+10 X.Org X server -- input driver metapackage ii xserver-xorg-input-evdev 1:2.6.99.901-1 X.Org X server -- evdev input driver ii xserver-xorg-input-synaptics 1.5.0+git20120101-1 Synaptics TouchPad driver for X.Org server ii xserver-xorg-video-intel 2:2.17.0+git20120115-1 X.Org X server -- Intel i8xx, i9xx display driver ii xserver-xorg-video-intel-dbg 2:2.17.0+git20120115-1 X.Org X server -- Intel i8xx, i9xx display driver (debug symbols) The action taken was to open a file in eog (initially successfully) and then maximising eog. X immediately crashed. Additionally, the following behaviour was observed: * Opening the same file in Iceweasel works - Switching tabulators away from the image-tab works in Iceweasel, too. - Switching back to the image-tab crashes X - similarly, operating the XFCE menu (which draws over the Iceweasel window) crashes X - Operating the file context menu (right click on image) of Iceweasel works * Opening the file in eog also works initially - maximising the window crashes X - operating the XFCE menu works (does not draw over eog window) - operating the file menu of eog crashes X * On all occasions, moving the mouse pointer over the area was no problem whatsoever. I will attach the corresponding log from X shortly. I also recorded logs/backtraces from Iceweasel-induced crashes, but they appear to be similar. Do I also have to upload these?
Created attachment 56241 [details] Log corresponding to previously attached backtrace
You found a path that escaped sanity checking, I failed to assert that the mmapped upload buffer will be mappable. With a more recent ddx you cannot hit that particular path, and I'm adding the sanity checks in case it crops up elsewhere.
I've pushed the safeguard commit 2afd49a28429cdeb36583cfc31cc9b1742c1fb83 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jan 27 22:18:30 2012 +0000 sna: Limit inplace upload buffers to maximum mappable size References: https://bugs.freedesktop.org/show_bug.cgi?id=45323 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> and have already prevented that code path from occurring, so I think I can safely close this bug.
First of all, thank you very much for your work! Reporting a bug at 15:49 (to Debian) and seeing a fix pushed at 00:46 is more than just awesome :) I will test it as soon as the fixed packages are in Debian Experimental, as I am a bit wary of building X myself.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.