0: /usr/bin/X(xf86SigHandler+0x81) [0x80c3971]
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 188.8.131.52
Release Date: 21 December 2005
X Protocol Version 11, Revision 0, Release 184.108.40.206
Build Operating System: UNKNOWN
Current Operating System: Linux fridge 2.6.182-src #5 Wed Nov 8 20:47:17 CET 200
0: /usr/bin/X(xf86SigHandler+0x7e) [0x80c092e]
2: /usr/lib/xorg/modules/extensions//libGLcore.so(XMesaResizeBuffers+0x29) [0xaf
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
<wait for RADEONSaveScreen(2)>
# DISPLAY=:0 glxinfo
<wait for RADEONSaveScreen(2)>
# DISPLAY=:0 glxinfo
0: X(xf86SigHandler+0x7e) [0x80c092e]
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.
on Jan 24, 2017 at 21:19:39.
(provided by the Example extension).