Bug 9212 - crash on second server reset
crash on second server reset
Status: RESOLVED FIXED
Product: DRI
Classification: Unclassified
Component: General
DRI git
x86 (IA32) Linux (All)
: high normal
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-30 14:59 UTC by Michal Suchanek
Modified: 2009-05-20 05:38 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michal Suchanek 2006-11-30 14:59:18 UTC
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.
Comment 1 Alan Hourihane 2006-12-01 01:04:35 UTC
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.
Comment 2 Michal Suchanek 2006-12-01 15:01:29 UTC
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.
Comment 3 Michal Suchanek 2006-12-02 03:09:29 UTC
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]
Comment 4 Michel Dänzer 2006-12-04 03:32:27 UTC
(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?
Comment 5 Michal Suchanek 2006-12-05 05:37:59 UTC
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.

Comment 6 Michel Dänzer 2006-12-05 05:44:51 UTC
Neither the GLcore module nor the __glXleaveServer() function should be involved
with a direct rendering context.
Comment 7 Michal Suchanek 2006-12-07 04:07:49 UTC
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.
Comment 8 Michal Suchanek 2006-12-08 10:32:34 UTC
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]

Comment 9 Michal Suchanek 2006-12-08 10:37:22 UTC
hmm, I get crash when using xdpyinfo instead of glxinfo. Possibly not OpenGL at all.
Comment 10 Michal Suchanek 2006-12-09 21:44:40 UTC
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 ***
Comment 11 Michel Dänzer 2006-12-11 08:02:07 UTC
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.
Comment 12 Michal Suchanek 2007-01-05 14:40:48 UTC
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?
Comment 13 Michel Dänzer 2007-01-06 10:14:50 UTC
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.
Comment 14 Tormod Volden 2007-04-07 12:22:32 UTC
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.
Comment 15 Jerome Glisse 2009-05-20 05:38:24 UTC
This bug is likely fixed, please reopen if you still have this issue with recent mesa and xf86-video-ati.