Bug 55602 - xf86-video-intel 2.20.9 segfaults on startx (Intel GMA HD on original Core i5-460M)
Summary: xf86-video-intel 2.20.9 segfaults on startx (Intel GMA HD on original Core i5...
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Chris Wilson
QA Contact: Xorg Project Team
Depends on:
Reported: 2012-10-04 02:11 UTC by joseph yarbrough
Modified: 2012-10-08 16:42 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Xorg logfile (37.96 KB, text/plain)
2012-10-04 21:36 UTC, joseph yarbrough
no flags Details
console output (932 bytes, text/plain)
2012-10-04 21:37 UTC, joseph yarbrough
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description joseph yarbrough 2012-10-04 02:11:22 UTC
xf86-video-intel 2.20.9-1 seg faults on an original Core i5-460M Intel GMA HD.

I tried to get the output, but "2>&1 > log" didn't work. 

I will try to get more information. This only started with this update.

Please let me know what logs/information I can provide to help.
Comment 1 Chris Wilson 2012-10-04 09:11:06 UTC
A backtrace from gdb would be best, but first please attach the Xorg.0.log and any xdm.log (or gdm.log or kdm.log etc).
Comment 2 joseph yarbrough 2012-10-04 21:36:21 UTC
Created attachment 68095 [details]
Xorg logfile
Comment 3 joseph yarbrough 2012-10-04 21:37:40 UTC
Created attachment 68096 [details]
console output
Comment 4 joseph yarbrough 2012-10-04 21:40:35 UTC
Here you are good sir. I'm happy to assist in any way I can. I have not used gdb in 15 years, so I can't do that part for you yet.

I'll search/create another bug report for another bug I found concerning HDMI output. It turns the external monitor on, but it stays black. It also causes the monitor display to corrupt and display garbage. I'm installing sshd now so I don't have to hard boot to get the system back.
Comment 5 Chris Wilson 2012-10-04 22:09:43 UTC
Do you have a rotation set upon your display? It looks like it should be fixed by

commit 8c2821d77c4b3bdd4d40d4a2c69f935a9eb0fd47
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Oct 2 11:31:40 2012 +0100

    sna: Remember to call ValidatePicture() before using newly created Pictures
    Reported-by: Marco De Michele <marco.demichele@taolab.it>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55527
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Comment 6 wes 2012-10-05 21:38:27 UTC
Hi!  I have what I think to be the same issue.  More information here:


The crash happens when I make an xrandr call.  You can find a backtrace in the post.
Comment 7 wes 2012-10-05 21:46:19 UTC
Sorry for the added noise.  I see this has already been resolved.
Comment 8 Chris Wilson 2012-10-07 17:02:20 UTC
I'm pretty sure this was the aforementioned issue...

*** This bug has been marked as a duplicate of bug 55527 ***
Comment 9 Andy 2012-10-08 10:33:06 UTC
I actually think that these are two issues. I can confirm the original bug submitted by joseph yarbrough. I am running Arch Linux on a very recent Thinkpad X230 with i7 cpu but do not make use of any display rotations or external displays. My Xorg.log looks exactly as the one of joseph, i.e. 

[  8787.362] Backtrace:
[  8787.362] 0: /usr/bin/X (xorg_backtrace+0x36) [0x560366]
[  8787.362] 1: /usr/bin/X (0x400000+0x1640c9) [0x5640c9]
[  8787.362] 2: /usr/lib/libpthread.so.0 (0x7ff9f7d76000+0xf170) [0x7ff9f7d85170]
[  8787.362] 3: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff9f4d4d000+0x6482e) [0x7ff9f4db182e]
[  8787.362] 4: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff9f4d4d000+0x6340a) [0x7ff9f4db040a]
[  8787.362] 5: /usr/bin/X (0x400000+0xf2119) [0x4f2119]
[  8787.362] 6: /usr/bin/X (0x400000+0xeb084) [0x4eb084]
[  8787.362] 7: /usr/bin/X (0x400000+0x34531) [0x434531]
[  8787.362] 8: /usr/bin/X (0x400000+0x23615) [0x423615]
[  8787.362] 9: /usr/lib/libc.so.6 (__libc_start_main+0xf5) [0x7ff9f6c22725]
[  8787.362] 10: /usr/bin/X (0x400000+0x238ed) [0x4238ed]
[  8787.362] 
[  8787.362] Segmentation fault at address (nil)
[  8787.362] 
Fatal server error:
[  8787.362] Caught signal 11 (Segmentation fault). Server aborting

X starts properly but the server gets killed after some time. This happens rather regularly. X was running properly without any issue before a recent update to xf86-video-intel 2.20.9-1. 

Any help on this would be very welcome.
Comment 10 Chris Wilson 2012-10-08 10:35:39 UTC
So you didn't try the fix proposed, nor decode the stacktrace into something I can use?
Comment 11 Andy 2012-10-08 11:34:06 UTC
I have not downgraded the driver, though I will probably as a workaround. The xrandr command provided in the mentioned bug report does not cause any problem on my system. Moreover I do not have any action available that allows me to reproduce the error, it just happens from time to time (4 times already today). Anyway I am running gdb now to debug the process. I will post a backtrace once the error reappears.
Comment 12 Chris Wilson 2012-10-08 11:49:16 UTC
Downgraded? You do not have a version of the drivers with the latest fixes.

All you need to do for the time being is 'addr2line -e usr/lib/xorg/modules/drivers/intel_drv.so 0x6482e 0x6340a', using gdb to get a better stacktrace is preferable though.
Comment 13 joseph yarbrough 2012-10-08 14:04:43 UTC
I am unable to give more information because I was forced to install windows because I could not get other devices on my laptop to work and I need the system stable for school.

I should note that I had scripts that were suppose to run on startup that did xrandr for screen adjustment, and xinput for the touchscreen matrix.

I'm not sure at what point xfce4 runs those commands, but I wasn't getting any screen output before X would crash.

I wish I could offer more assistance. :(
Comment 14 Andy 2012-10-08 16:42:10 UTC
Thank you for pointing this out but 'addr2line -e /usr/lib/xorg/modules/drivers/intel_drv.so 0x6482e 0x6340a' only returns ??:0 (addresses of course adjusted to the Xorg.log output). Since I did not compile from source I figured that by default the debug symbols are not available. 

It actually seems that this is an Arch Linux issue, at least in my case:


Going back to 2.20.8-1 solves the problem and X keeps running stable.

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.