Backtrace: 0: /usr/bin/X(xf86SigHandler+0x81) [0x80c3971] 1: [0xb7f9f420] 2: /usr/lib/xorg/modules/extensions/libglx.so [0xb7c85946] 3: /usr/lib/xorg/modules/extensions/libglx.so(__glXleaveServer+0x22) [0xb7c61c62] 4: /usr/lib/xorg/modules/extensions/libglx.so [0xb7c622fe] 5: /usr/bin/X(Dispatch+0x18f) [0x808693f] 6: /usr/bin/X(main+0x485) [0x806e715] 7: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc) [0xb7da08cc] 8: /usr/bin/X(FontFileCompleteXLFD+0xa1) [0x806da51] gxl appears in the backtrace so it is probably related. I have an application that opens a gtk window, closes it, and then opens a fullscreen window in a different videomode to render using OpenGL. If I start it from Gnome, it works. If I start it without a windownamager the X server crashes just when the videomode is about to be switched. With pwm3 it does not work either (incidentally, pwm3 is misconfigured and does not display any fonts). With Metacity (the Gnome WM) it works. iirc it worked on mga. I hope this is the right place to report this. I am a bit confused by the number of different modules that are involved.
Are you running dual head ? This looks suspiciously like a crash in the server in 7.1, that's fixed in the upcoming 7.2 server.
no, I am running single analog screen connected to the dvi connector. Now I noticed that it works when the program is started as the first session. If a gnome session was started and terminated on the same X server it crashes. I may as well try to get the latest server code. I will try to do more testing.
With latest X server it still crashes. X Window System Version 7.1.99.2 Release Date: 21 December 2005 X Protocol Version 11, Revision 0, Release 7.1.99.2 Build Operating System: UNKNOWN Current Operating System: Linux fridge 2.6.182-src #5 Wed Nov 8 20:47:17 CET 200 6 i686 Backtrace: 0: /usr/bin/X(xf86SigHandler+0x7e) [0x80c092e] 1: [0xb7fd6420] 2: /usr/lib/xorg/modules/extensions//libGLcore.so(XMesaResizeBuffers+0x29) [0xaf 9dc3a9] 3: /usr/lib/xorg/modules/extensions//libGLcore.so [0xaf9d8fb0] 4: /usr/lib/xorg/modules/extensions//libglx.so [0xb7c7667a] 5: /usr/bin/X(ReparentWindow+0x1ac) [0x807564c] 6: /usr/bin/X(ProcReparentWindow+0xd5) [0x8087d35] 7: /usr/bin/X [0x813a4d1] 8: /usr/bin/X(Dispatch+0x1ba) [0x808831a] 9: /usr/bin/X(main+0x495) [0x806f295] 10: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc) [0xb7deb8cc] 11: /usr/bin/X(FontFileCompleteXLFD+0xad) [0x806e5c1]
(In reply to comment #3) > With latest X server it still crashes. Looks like a different crash though. BTW, any reason for not using direct rendering?
I am using direct rendering. In fact, the program refuses to start if direct rendering is not available. If direct rendering was not available it would cause the program to terminate somewhere about the time the crash occurs.
Neither the GLcore module nor the __glXleaveServer() function should be involved with a direct rendering context.
I have checked dhe dri status in the first and second session. Apparently dri is lost on server reset, and the second session does indirect rendering. Since the OpenGL app is run as the session it probably opens the fullscreen window, checks if it is dri enabled, and exits. xinit then terminates the session. The X server must crash somewhere around that time then.
I get yet another different trace with # X& <wait for RADEONSaveScreen(2)> # DISPLAY=:0 glxinfo <wait for RADEONSaveScreen(2)> # DISPLAY=:0 glxinfo Backtrace: 0: X(xf86SigHandler+0x7e) [0x80c092e] 1: [0xb7f3e420] 2: /usr/lib/xorg/modules/extensions//libglx.so [0xb7c03f35] 3: /usr/lib/xorg/modules/extensions//libglx.so(__glXInitScreens+0x9c) [0xb7bcf4fc] 4: /usr/lib/xorg/modules/extensions//libglx.so(GlxExtensionInit+0x105) [0xb7bce4f5] 5: X(InitExtensions+0xa2) [0x80eb602] 6: X(main+0x2b5) [0x806f0b5] 7: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc) [0xb7d44ebc] 8: X(FontFileCompleteXLFD+0xad) [0x806e5c1]
hmm, I get crash when using xdpyinfo instead of glxinfo. Possibly not OpenGL at all.
Looks like it is the same thing. Either dri is disabled after reset and the server crashes on the second reset or dri works and the server does not crash. *** This bug has been marked as a duplicate of 9275 ***
Hold your horses. ;) The same symptoms described in bug 9275 could be caused differently, e.g. by clients that keep the DRM open while the X server resets, and this crash might still occur then. You might be able to verify this (once bug 9275 has been fixed) with something like 3ddesktop, which tends not to quit on session exit.
ok, i have a patch that fixes (or at least works around) the issue that dri is disabled X reset. How would I test that this is also fixed?
As I said in comment #11, by keeping the DRM device open while the X server resets. E.g. you could write a small program that just opens /dev/dri/card0 and then sleeps indefinitely.
The stack trace in the bug description seems identical to the one in https://bugs.launchpad.net/bugs/60288 which has been fixed in 7.2, and which occurred also without dual head. However, the other stack traces seem different.
This bug is likely fixed, please reopen if you still have this issue with recent mesa and xf86-video-ati.
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.