Under normal usage, segfaults (as below) with some regularity. rdesktop used to be my primary culprit and I changed to xfreerdp. Now it appears that the Oracle Beehive web conference java client is a likely culprit. X.Org X Server 1.15.1 Release Date: 2014-04-13 X Protocol Version 11, Revision 0 Build Operating System: Linux 3.14.0-4-ARCH x86_64 Current Operating System: Linux ... 3.15.1-1-ARCH #1 SMP PREEMPT Tue Jun 17 09:32:20 CEST 2014 x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=73242017-c757-45f8-bc0e-9deb5f972d8e rw quiet Build Date: 14 April 2014 08:39:09AM xf86-video-intel 2.99.912-1 is the vid driver *** BUG *** In pixman_region_append_non_o: The expression r->x1 < r->x2 was false Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region_append_non_o: The expression r->x1 < r->x2 was false Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region_append_non_o: The expression r->x1 < r->x2 was false Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region_append_non_o: The expression r->x1 < r->x2 was false Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region_append_non_o: The expression r->x1 < r->x2 was false Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region_append_non_o: The expression r->x1 < r->x2 was false Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region_append_non_o: The expression r->x1 < r->x2 was false Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region_append_non_o: The expression r->x1 < r->x2 was false Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region_append_non_o: The expression r->x1 < r->x2 was false Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region_append_non_o: The expression r->x1 < r->x2 was false Set a breakpoint on '_pixman_log_error' to debug (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x48) [0x584b08] (EE) 1: /usr/bin/X (0x400000+0x1887f9) [0x5887f9] (EE) 2: /usr/lib/libpthread.so.0 (0x7ff03ae8d000+0xf4b0) [0x7ff03ae9c4b0] (EE) 3: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff034704000+0x20fd0) [0x7ff034724fd0] (EE) 4: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff034704000+0x50baf) [0x7ff034754baf] (EE) 5: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff034704000+0x32a59) [0x7ff034736a59] (EE) 6: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff034704000+0x32d1e) [0x7ff034736d1e] (EE) 7: /usr/bin/X (0x400000+0x112258) [0x512258] (EE) 8: /usr/bin/X (0x400000+0x321e1) [0x4321e1] (EE) 9: /usr/bin/X (0x400000+0x35c8e) [0x435c8e] (EE) 10: /usr/bin/X (0x400000+0x39aaa) [0x439aaa] (EE) 11: /usr/lib/libc.so.6 (__libc_start_main+0xf0) [0x7ff039afa000] (EE) 12: /usr/bin/X (0x400000+0x2507e) [0x42507e] (EE) (EE) Segmentation fault at address 0x7ff12ec94160 (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) (EE)
Hmm, fixed a damage related bug, but that feels different to this. Can you try compiling from xf86-video-intel.git with --enable-debug? Note if it asserts, and send me the compressed log file?
Of course, getting a symbolic stacktrace either using gdb, or "addr2line -e /usr/lib/xorg/modules/drivers/intel_drv.so -i 0x20fd0 0x50baf 0x32a59 0x32d1e" would be invaluable
addr2line -e /usr/lib/xorg/modules/drivers/intel_drv.so -i 0x20fd0 0x50baf 0x32a59 0x32d1e :? sna_accel.c:? sna_accel.c:? sna_accel.c:? Hrmm... how much of the Xorg stack needs to be built as debug to get everything needed?
This requires xf86-video-intel to be unstripped.
~ > file /usr/lib/xorg/modules/drivers/intel_drv.so /usr/lib/xorg/modules/drivers/intel_drv.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=49eb40479430aa9be404808b264c949a9dc1b853, not stripped
The other key point being that I haven't yet reproduced the segfault... still working on that one.
If you rebuilt using the same source, there is a good chance the addresses still match and you can repeat the addr2line to get the right symbols...
Well, that addr2line was on the non-stripped file, hence why I asked if there was more to it than just the driver package that needed to be rebuilt. As of right now I am running the 2 primary crashers (rdesktop and java Beehive conferencing app) and I have been unable to reproduce it. Any chance you threw in a logger when the issue would have occurred if you hadn't fixed it?
Not unless it gets caught by --enable-debug.
Ok, we're far beyond the point where I would expect this thing to segfault again. I'll be running this daily and will report if it does wind up dying.
Thanks for the update. Let me know how it fares over a soak test.
Let's just assume it was fixed... Should be enough to cause it to trigger again.
I agree, I have been having zero issues and made a point of running the culprit apps far more than usual.
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.