Xorg crashing 5 minutes after resume with segmentation fault

[Romano Giannetti]

Intel graphic dreiver on an asus eeepc 1005ha, using Gnome Shell. This is a regression triggered by the recent Xorg upgrade.
After around five minutes since resume, the X server crashed. I will attach the relevant log, the crash is here:
Backtrace:
[ 85883.610] 0: /usr/bin/X (xorg_backtrace+0x37) [0xd9b607]
[ 85883.611] 1: /usr/bin/X (0xc13000+0x18c38a) [0xd9f38a]
[ 85883.611] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0x24940c]
[ 85883.611] 3: /usr/bin/X (XIChangeDeviceProperty+0x1b8) [0xd33b28]
[ 85883.611] 4: /usr/bin/X (0xc13000+0x121188) [0xd34188]
[ 85883.611] 5: /usr/bin/X (0xc13000+0x116f77) [0xd29f77]
[ 85883.611] 6: /usr/bin/X (0xc13000+0x3791d) [0xc4a91d]
[ 85883.611] 7: /usr/bin/X (0xc13000+0x2535a) [0xc3835a]
[ 85883.612] 8: /lib/i386-linux-gnu/libc.so.6 (__libc_start_main+0xf3) [0x2634d3
]
[ 85883.612] 9: /usr/bin/X (0xc13000+0x25699) [0xc38699]
[ 85883.612] Segmentation fault at address 0x9
[ 85883.612]
Caught signal 11 (Segmentation fault). Server aborting
[ 85883.651]

After loggin in back, the apport system (which I have enabled) ask to report a bug, then it (apport, I mean) crashes with a segfault and after that the new apport on apport crashes too.

Requested info:
(0)romano-asus:/var/log% lsb_release -rd
Description: Ubuntu 12.04 LTS
Release: 12.04
(0)romano-asus:/var/log% apt-cache policy xorg
xorg:
  Installed: 1:7.6+12ubuntu1
  Candidate: 1:7.6+12ubuntu1
  Version table:
 *** 1:7.6+12ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ precise/main i386 Packages
        100 /var/lib/dpkg/status

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Romano Giannetti (romano-giannetti)]

Has anyone any hints on this? It is really obnoxious.

I *think* it happens when using nautilus, but I cannot be sure.

Some hints on how to debug?

[Kevin Kong (kevin1078-kong)]

I also have the exact same bug in my Lenovo T400s. It's not 5 minutes around but randomly, about several times a day, and has not fixed steps to reproduce.

Backtrace:
[ 7501.237] 0: /usr/bin/X (xorg_backtrace+0x37) [0xb7743627]
[ 7501.237] 1: /usr/bin/X (0xb75bb000+0x18c3aa) [0xb77473aa]
[ 7501.237] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xb759840c]
[ 7501.237] 3: /usr/bin/X (XIGetDeviceProperty+0x38) [0xb76dbd08]
[ 7501.237] 4: /usr/bin/X (0xb75bb000+0x120db7) [0xb76dbdb7]
[ 7501.237] 5: /usr/bin/X (0xb75bb000+0x12140f) [0xb76dc40f]
[ 7501.237] 6: /usr/bin/X (0xb75bb000+0x116f97) [0xb76d1f97]
[ 7501.237] 7: /usr/bin/X (0xb75bb000+0x3791d) [0xb75f291d]
[ 7501.237] 8: /usr/bin/X (0xb75bb000+0x2535a) [0xb75e035a]
[ 7501.237] 9: /lib/i386-linux-gnu/libc.so.6 (__libc_start_main+0xf3) [0xb721b4d3]
[ 7501.238] 10: /usr/bin/X (0xb75bb000+0x25699) [0xb75e0699]
[ 7501.238] Segmentation fault at address 0xd
[ 7501.238]
Caught signal 11 (Segmentation fault). Server aborting
[ 7501.238]

[Romano Giannetti (romano-giannetti)]

Yes, five minutes was an approximate thing. It crashed on me today few seconds after resume, mad yesterday after more than one hour work.
If only apport would work. I have seen something about a crash in XInspectProperty or something similar...

[Kevin Kong (kevin1078-kong)]

Hey guys, I found that if you purge cache periodically, you can postpone the crashing to a large extent, though it's still inevitable. So I guess the problem is related to the system cache mechanism. Hope this is useful to you!

[Romano Giannetti (romano-giannetti)]

@Kevin: which cache are you referring to? Thanks!

Can someone tell me how can I use apport manually? I have this sensation that the apport-gtk is to blame for the apport crash, and having another way to obtain a text-only trace could help to nail it down.

[Kevin Kong (kevin1078-kong)]

Sorry, I forgot to attach the command line.

sudo su
echo 1 > /proc/sys/vm/drop_cache

But I'm not sure this trick really works now. The first time I tried it, I got a day's non-crash (usually it crashed 2 to 3 times a day). But later days, it seemed it did not take effect by executing this command, and returned back to 2 to 3 times crash a day again.

I also noticed that suspending Ubuntu will cause the crash more frequently. But it does not mean that Xorg will not crash if you do not suspend Ubuntu.

It's really complicated.

[Kevin Kong (kevin1078-kong)]

It seems this problem will not occur again after the kernel is updated from 2.6.3x to 3.2.x. I already worked on 3.2.x for several days, and haven't see crashes again.