Bug 9212

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.