| Summary: | [i915][GM45]: xorg-server-1.9.2 crashes w/ all KDE OpenGL screen savers | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Toralf Förster <toralf.foerster> |
| Component: | Drivers/DRI/i965 | Assignee: | Eric Anholt <eric> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 7.10 | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Well, the log file gives : Backtrace: [ 2448.835] 0: /usr/bin/X (xorg_backtrace+0x3c) [0x80ea6fc] [ 2448.836] 1: /usr/bin/X (0x8048000+0x60fc1) [0x80a8fc1] [ 2448.836] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xb782e40c] [ 2448.836] 3: /usr/lib/dri/i965_dri.so (0xb6de8000+0x5107f) [0xb6e3907f] [ 2448.836] 4: /usr/lib/dri/i965_dri.so (0xb6de8000+0x422f8) [0xb6e2a2f8] [ 2448.836] 5: /usr/lib/dri/i965_dri.so (0xb6de8000+0x1277ba) [0xb6f0f7ba] [ 2448.836] 6: /usr/lib/dri/i965_dri.so (0xb6de8000+0x12336f) [0xb6f0b36f] [ 2448.836] 7: /usr/lib/dri/i965_dri.so (0xb6de8000+0x124f90) [0xb6f0cf90] [ 2448.836] 8: /usr/lib/dri/i965_dri.so (0xb6de8000+0x878d1) [0xb6e6f8d1] [ 2448.836] 9: /usr/lib/xorg/modules/extensions/libglx.so (0xb73d7000+0x86b2) [0xb73df6b2] [ 2448.836] 10: /usr/lib/xorg/modules/extensions/libglx.so (0xb73d7000+0x328c5) [0xb74098c5] [ 2448.836] 11: /usr/lib/xorg/modules/extensions/libglx.so (0xb73d7000+0x37403) [0xb740e403] [ 2448.837] 12: /usr/bin/X (0x8048000+0x29437) [0x8071437] [ 2448.837] 13: /usr/bin/X (0x8048000+0x1d70a) [0x806570a] [ 2448.837] 14: /lib/libc.so.6 (__libc_start_main+0xe6) [0xb754abb6] [ 2448.837] 15: /usr/bin/X (0x8048000+0x1d2c1) [0x80652c1] [ 2448.837] Segmentation fault at address (nil) [ 2448.837] Fatal server error: [ 2448.837] Caught signal 11 (Segmentation fault). Server aborting [ 2448.837] [ 2448.838] Please consult the The X.Org Foundation support but I'm unsure whether this is the crash from OpenGL or whether this is only related to bug #32822 (which BTW then would be still present in 1.9.3.901) It is not related to bug #32822, happens with xorg-1.9.4 and mesa-7.10 too here at an almost stable Gentoo, current backtrace is : Backtrace: 0: /usr/bin/X (xorg_backtrace+0x3c) [0x80ea81c 1: /usr/bin/X (0x8048000+0x61121) [0x80a9121 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xb77e740c 3: /usr/lib/dri/i965_dri.so (0xb6d8d000+0x54d4f) [0xb6de1d4f 4: /usr/lib/dri/i965_dri.so (0xb6d8d000+0x44848) [0xb6dd1848 5: /usr/lib/dri/i965_dri.so (0xb6d8d000+0x1198fa) [0xb6ea68fa 6: /usr/lib/dri/i965_dri.so (0xb6d8d000+0x11128f) [0xb6e9e28f 7: /usr/lib/dri/i965_dri.so (0xb6d8d000+0x1112d8) [0xb6e9e2d8 8: /usr/lib/dri/i965_dri.so (0xb6d8d000+0xe7c24) [0xb6e74c24 9: /usr/lib/dri/i965_dri.so (0xb6d8d000+0xe7cf1) [0xb6e74cf1 10: /usr/lib/xorg/modules/extensions/libglx.so (0xb7390000+0x7cbf) [0xb7397cbf 11: /usr/lib/xorg/modules/extensions/libglx.so (0xb7390000+0x328c5) [0xb73c28c5 12: /usr/lib/xorg/modules/extensions/libglx.so (0xb7390000+0x37403) [0xb73c7403 13: /usr/bin/X (0x8048000+0x294a7) [0x80714a7 14: /usr/bin/X (0x8048000+0x1d77a) [0x806577a 15: /lib/libc.so.6 (__libc_start_main+0xe6) [0xb7503bb6 16: /usr/bin/X (0x8048000+0x1d331) [0x8065331 Segmentation fault at address (nil) Step 1, test http://www.mail-archive.com/xorg-devel@lists.x.org/msg18111.html and reply with your tested-by Step 2, stop using indirect rendering on your local machine. Step 3, attach gdb to the now direct rendering processing and get a meaningful stacktrace. (In reply to comment #3) > Step 1, test http://www.mail-archive.com/xorg-devel@lists.x.org/msg18111.html > and reply with your tested-by I'd like to do that however I get : $> patch -p1 < /usr/local/portage/x11-base/xorg-server/files/GL-crash.patch patching file glx/indirect_table.c Hunk #1 succeeded at 189 (offset 1 line). patch: **** malformed patch at line 39: Render_size_func_table[74] = { Is that patch applicable for 1.94 ? Or - even better - pls could you attach it here onto this bug report b/c probably sth. went wrong w/ copying the patch from that html page. bugzilla-daemon@freedesktop.org wrote at 10:54:44 > https://bugs.freedesktop.org/show_bug.cgi?id=32932 > > --- Comment #3 from Chris Wilson <chris@chris-wilson.co.uk> 2011-02-10 > 01:54:44 PST --- Step 1, test > http://www.mail-archive.com/xorg-devel@lists.x.org/msg18111.html and reply > with your tested-by > Step 2, stop using indirect rendering on your local machine. > Step 3, attach gdb to the now direct rendering processing and get a > meaningful stacktrace. Is this meaningfull enough ? : (If not I'll continue but it is hard b/c after I aattach tge gdb to the running X then I cannot longer switch from a console to the running X display or back,but found now some more hints to do that) : Core was generated by `/usr/bin/X -br -novtswitch -quiet :0 vt7 -nolisten tcp -auth /var/run/xauth/A:0'. Program terminated with signal 6, Aborted. #0 0xb77fc424 in __kernel_vsyscall () (gdb) bt #0 0xb77fc424 in __kernel_vsyscall () #1 0xb752c401 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb752db42 in abort () at abort.c:92 #3 0x080aa0ed in OsAbort () at utils.c:1274 #4 0x080b825d in ddxGiveUp () at xf86Init.c:940 #5 0x080b830c in AbortDDX () at xf86Init.c:986 #6 0x080a7c0e in AbortServer () at log.c:424 #7 0x080a833e in FatalError (f=0x81d163c "Caught signal %d (%s). Server aborting\n") at log.c:552 #8 0x080a9181 in OsSigHandler (signo=11, sip=0xbfeaefbc, unused=0xbfeaf03c) at osinit.c:156 #9 <signal handler called> #10 0xb6e10e12 in ?? () from /usr/lib/dri/i965_dri.so #11 0xb6df8d4f in ?? () from /usr/lib/dri/i965_dri.so #12 0xb6de8848 in ?? () from /usr/lib/dri/i965_dri.so #13 0xb6ebd8fa in ?? () from /usr/lib/dri/i965_dri.so #14 0xb6eb528f in ?? () from /usr/lib/dri/i965_dri.so #15 0xb6eb52d8 in ?? () from /usr/lib/dri/i965_dri.so #16 0xb6f969b1 in ?? () from /usr/lib/dri/i965_dri.so #17 0xb73ad6b2 in ?? () from /usr/lib/xorg/modules/extensions/libglx.so #18 0xb73d79a5 in ?? () from /usr/lib/xorg/modules/extensions/libglx.so #19 0xb73dc4e3 in ?? () from /usr/lib/xorg/modules/extensions/libglx.so #20 0x080714a7 in Dispatch () at dispatch.c:432 #21 0x0806577a in main (argc=10, argv=0xbfeaf7d4, envp=0xbfeaf800) at main.c:291 FWIW I attach here the backtrace of the process krunner (which calls kscreensaver which then runs "atlantis" (from xscreensaver) which reliable reproduce the crash) :
(gdb) bt
#0 0xb7767424 in __kernel_vsyscall ()
#1 0xb5ec61f6 in __poll (fds=0xb5f43ff4, nfds=8, timeout=451) at ../sysdeps/unix/sysv/linux/poll.c:87
#2 0xb593d15c in g_poll (fds=0x8e13808, nfds=8, timeout=451) at gpoll.c:132
#3 0xb592f9ac in g_main_context_poll (context=0x8ab3a90, block=<value optimized out>, dispatch=1, self=0x8ab14e8) at gmain.c:3093
#4 g_main_context_iterate (context=0x8ab3a90, block=<value optimized out>, dispatch=1, self=0x8ab14e8) at gmain.c:2775
#5 0xb592fdd9 in g_main_context_iteration (context=0x8ab3a90, may_block=1) at gmain.c:2843
#6 0xb6c7f496 in QEventDispatcherGlib::processEvents (this=0x8ab1050, flags=...) at kernel/qeventdispatcher_glib.cpp:412
#7 0xb62331f6 in QGuiEventDispatcherGlib::processEvents (this=0x8ab1050, flags=...) at kernel/qguieventdispatcher_glib.cpp:204
#8 0xb6c519ea in QEventLoop::processEvents (this=0xbfb5e1f4, flags=) at kernel/qeventloop.cpp:149
#9 0xb6c51e4a in QEventLoop::exec (this=0xbfb5e1f4, flags=...) at kernel/qeventloop.cpp:201
#10 0xb6c570e1 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1003
#11 0xb6175bf8 in QApplication::exec () at kernel/qapplication.cpp:3581
#12 0xb38f8e0e in kdemain (argc=1, argv=0x8a8b7b0) at /var/tmp/portage/kde-base/krunner-4.4.5/work/krunner-4.4.5/krunner/main.cpp:65
#13 0x0804e453 in launch (argc=<value optimized out>, _name=<value optimized out>, args=<value optimized out>, cwd=0x0, envc=0,
envs=0x8a8b841 "", reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x80516e5 "0")
at /var/tmp/portage/kde-base/kdelibs-4.4.5-r2/work/kdelibs-4.4.5/kinit/kinit.cpp:710
#14 0x0804ef55 in handle_launcher_request (sock=<value optimized out>, who=<value optimized out>)
at /var/tmp/portage/kde-base/kdelibs-4.4.5-r2/work/kdelibs-4.4.5/kinit/kinit.cpp:1202
#15 0x0804f36c in handle_requests (waitForPid=<value optimized out>)
at /var/tmp/portage/kde-base/kdelibs-4.4.5-r2/work/kdelibs-4.4.5/kinit/kinit.cpp:1395
#16 0x080500a5 in main (argc=4, argv=0xbfb5ec74, envp=0xbfb5ec88)
at /var/tmp/portage/kde-base/kdelibs-4.4.5-r2/work/kdelibs-4.4.5/kinit/kinit.cpp:1838
Well and I'm completely blind, b/c it is a dup of bug #32822 *shame* *** This bug has been marked as a duplicate of bug 32822 *** (In reply to comment #7) > Well and I'm completely blind, b/c it is a dup of bug #32822 *shame* > > *** This bug has been marked as a duplicate of bug 32822 *** No need to blame yourself. The problem here is with Gentoo's eselect opengl script, which doesn't care enough about debug symbol files when shuffling around GL related libs. Therefore virtually no Gentoo system has symbolic debug information ready when X crashes with GL libraries. There are are several directories involved: $lib/opengl/xorg-x11/extensions $lib/xorg/modules/extensions $lib/debug/$lib/opengl/xorg-x11/extensions $lib/debug/$lib/xorg/modules/extensions eselect opengl does set the library links themselfes correctly, but puts wrong links to their corresponding debug information files. So (sym-) linking the debug files to their correct locations manually fixes that. For example: /usr/lib64/opengl/xorg-x11/extensions/libglx.so /usr/lib64/xorg/modules/extensions/libglx.so -> ../../../opengl/xorg-x11/extensions/libglx.so /usr/lib64/debug/usr/lib64/xorg/modules/extensions/libglx.so.debug -> ../../../opengl/xorg-x11/extensions/libglx.so.debug |
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.
as soon as I try to quit the screen saver by type in my password. The only solution is : tfoerste@n22 ~ $ cat /usr/share/X11/xorg.conf.d/99-noAIGLX.conf Section "ServerLayout" Identifier "AIGLX crashes X" Option "AIGLX" "False" EndSection Tested at a Lenovo ThinkPad T400, stable Gentoo, kernel 2.6.37, xorg-1.9.3.901 (1.9.2.902 and 1.9.2), itnel drive 2.13.0 and mesa 7.9.1. The backtrace in /var/log/Xorg.0.log isn't very useful (2-4 lines) - although I compiled both xorg-server and intel driver with CFLAGS="-O2 -march=native -pipe -g -ggdb"