Bug 10752

Created attachment 9731 [details]
Crash dump from Xorg.log and kdm.log

The same crash-dump in a file...

Looking better the logs I've found another line that maybe can help:

/usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/extensions//libglx.so: un
defined symbol: XAAEvictPixmaps

So strange... If I'm not wrong X 7.2 should include that function...

I can confirm this also using Xorg-git (with mesa-git)...
Also if compiz doesn't work properly with it (white or black screen), if I replace it using another manager/decorator, 

The output is similar:

(**) RADEON(0): Programming CRTC1, offset: 0x00000000
(**) RADEON(0): GRPH_BUFFER_CNTL from 30004c4c to 20217c7c
(**) RADEON(0): EngineRestore (32/32)
(**) RADEON(0): EngineRestore (32/32)
(**) RADEON(0): RADEONSaveScreen(2)
couldn't enable device 2

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x7e) [0x80c4eee]
1: [0xffffe420]
2: /usr/lib/dri/r300_dri.so(r300FlushCmdBuf+0x34) [0xaf6ee75d]
3: /usr/lib/dri/r300_dri.so(r300DestroyContext+0x15f) [0xaf6eb8ef]
4: /usr/lib/dri/r300_dri.so [0xaf6e3f2d]
5: /usr/lib/dri/r300_dri.so [0xaf6e0647]
6: /usr/lib/xorg/modules/extensions//libglx.so [0xb7ba3814]
7: /usr/lib/xorg/modules/extensions//libglx.so(__glXFreeContext+0x7d) [0xb7b6cd4
d]
8: /usr/lib/xorg/modules/extensions//libglx.so [0xb7b6d165]
9: /usr/bin/X(FreeClientResources+0x8e) [0x8074fce]
10: /usr/bin/X(CloseDownClient+0x1a8) [0x8086118]
11: /usr/bin/X(Dispatch+0x3dc) [0x808c2ec]
12: /usr/bin/X(main+0x495) [0x80738c5]
13: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc) [0xb7cdeebc]
14: /usr/bin/X(FontFileCompleteXLFD+0x1e5) [0x8072bf1]

(In reply to comment #0)
> DISPATCH ERROR! _glapi_add_dispatch failed to add glGetVertexAttribPointerv!
> DISPATCH ERROR! _glapi_add_dispatch failed to add glGetVertexAttribPointerv!

[...]

> Maybe should I upgrade also Xorg to git?

That might indeed help, the above errors could indicate an incompatibility. Beware though that you'll need the xserver master branch to build with current Mesa, which will also require upgrading some other (mostly input related) components due to the new input hotplugging support.

Alternatively, you could try getting a full backtrace with gdb, preferably with a /usr/lib/dri/r300_dri.so with debugging symbols.

I'm not sure the "DISPATCH ERROR" messages are leading to the crash.  r300FlushCmdBuf() seems to be the more likely place.

The DISPATCH ERROR messages are coming from _glapi_add_dispatch() returning -1.  You could insert some printfs before the "return -1" statements to see which is causing the problem.

(In reply to comment #4)
> (In reply to comment #0)
> > DISPATCH ERROR! _glapi_add_dispatch failed to add glGetVertexAttribPointerv!
> > DISPATCH ERROR! _glapi_add_dispatch failed to add glGetVertexAttribPointerv!
> 
> [...]
> 
> > Maybe should I upgrade also Xorg to git?
> 
> That might indeed help, the above errors could indicate an incompatibility.
> Beware though that you'll need the xserver master branch to build with current
> Mesa, which will also require upgrading some other (mostly input related)
> components due to the new input hotplugging support.

Well, I did that... I tried few days ago to compile also Xorg from git, and these errors/warnings goes away, but not the bug I'm talking about...

> Alternatively, you could try getting a full backtrace with gdb, preferably with
> a /usr/lib/dri/r300_dri.so with debugging symbols.

I've tried to do that, but I don't really know how I could get it... I mean, I've made a debugging version of my dri lib but then I don't know what should I load using gdb; I've loaded compiz but it didn't help me, while I've problems loading Xorg at all since after crash I can't read what's written on tty1 (it's a common bug of xorg ati module I think...)

(In reply to comment #5)
> I'm not sure the "DISPATCH ERROR" messages are leading to the crash. 
> r300FlushCmdBuf() seems to be the more likely place.

I do think the same...
As I said before using Xorg git these DISPATCH ERORRs goes away and this was my newer backtrace (using a debug version of dri):

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x81) [0x80c5d91]
1: [0xffffe420]
2: /usr/lib/dri/r300_dri.so [0xaf6b3ef5]
3: /usr/lib/dri/r300_dri.so(radeonGetLock+0x35b) [0xaf6b4311]
4: /usr/lib/dri/r300_dri.so(r300FlushCmdBuf+0x67) [0xaf6c0ab8]
5: /usr/lib/dri/r300_dri.so [0xaf6bca66]
6: /usr/lib/dri/r300_dri.so(r300DestroyContext+0x19c) [0xaf6bd048]
7: /usr/lib/dri/r300_dri.so [0xaf6b2192]
8: /usr/lib/dri/r300_dri.so [0xaf6ac9cd]
9: /usr/lib/xorg/modules/extensions//libglx.so [0xb7c5cc14]
10: /usr/lib/xorg/modules/extensions//libglx.so(__glXFreeContext+0x7d) [0xb7c268
9d]
11: /usr/lib/xorg/modules/extensions//libglx.so [0xb7c26cb5]
12: /usr/bin/X(FreeClientResources+0x85) [0x8075e65]
13: /usr/bin/X(CloseDownClient+0x1a8) [0x80863e8]
14: /usr/bin/X(Dispatch+0x2c6) [0x808c746]
15: /usr/bin/X(main+0x495) [0x8074785]
16: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc) [0xb7dafebc]
17: /usr/bin/X(FontFileCompleteXLFD+0x1e1) [0x8073ab1]

(In reply to comment #6)
> > Alternatively, you could try getting a full backtrace with gdb, preferably with
> > a /usr/lib/dri/r300_dri.so with debugging symbols.
> 
> I've tried to do that, but I don't really know how I could get it... I mean,
> I've made a debugging version of my dri lib but then I don't know what should I
> load using gdb;

IME the best way is to attach gdb to the running X server process from a remote login.

Same problem here, with a Radeon X550 (PCI-E), mesa 6.5.3 and xorg-server 1.3.0.0  Tomorrow I'l try to get a backtrace with gdb (time permitting).

On a side note, this release is FAST, in my little test with compiz I couldn't reproduce any of the minor slowdowns I experienced before, even when the "water effect" is active. Scrolling web pages in firefox is fast as well. I noticed a frame rate drop with 3dmark2001 under wine but almost every graphic glitch went away (especially a couple of problems which resembled the one described in bug #8250).

Created attachment 9818 [details]
gdb backtrace

Gdb backtrace. X crashed when I killed compiz.

Created attachment 9819 [details] [review]
Possible fix

Does this patch fix it?

(In reply to comment #10)
> Created an attachment (id=9819) [details]
> Possible fix
> 
> Does this patch fix it?
> 

Yes, that patch works here. :)

Works here as well.  It's nice to be able to switch back to metacity from beryl :-)

Pushed in 65faf023679988f93da82b4c7ebdc689f2094459 .

The patch looks OK to me.  Though, I'm curious to learn why glCtx->DrawBuffer is NULL in the first place.

I'm posting here just to confirm that it works also here...

Thanks for fixing ;)

Mass version move, cvs -> git