recent drivers: crashes in glXChannelRectSyncSGIX

[kir]

Seems I am not the first one who has this issue.. This happens (randomly, no pattern) with 8762 and 8774 (probably with older releases too). The typical scenario is: you are exiting some program, it starts closing windows, crash occurs. The typical backtrace looks like:

#0 0xb53d3c8a in glXChannelRectSyncSGIX () from /usr/lib/libGL.so.1
#1 0xb7d421b8 in ?? () from /usr/lib/libX11.so.6
#2 0xb7c8d10d in XCloseDisplay () from /usr/lib/libX11.so.6
.... program callstack

The /usr/lib/libGL.so.1 is:
/usr/lib/libGL.so.1 -> libGL.so.1.0.8774

More information:

Backtrace with debugging symbols present:

(gdb) bt full
#0 0xb53c7c8a in glXChannelRectSyncSGIX () from /usr/lib/libGL.so.1
No symbol table info available.
#1 0xb7d361b8 in __JCR_LIST__ () from /usr/lib/libX11.so.6
No symbol table info available.
#2 0xb7c8110d in XCloseDisplay (dpy=0x811a350) at ../../src/ClDisplay.c:67
ext = (_XExtension *) 0x8126478
i = 1

Registers information:

(gdb) info registers
eax 0x0 0
ecx 0x8126210 135422480
edx 0xffffffc0 -64
ebx 0x811a350 135373648
esp 0xbff30158 0xbff30158
ebp 0xbff30178 0xbff30178
esi 0x8126478 135423096
edi 0x811a350 135373648
eip 0xb53c7c8a 0xb53c7c8a
eflags 0x10282 66178
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51


Corresponding source lines from ClDisplay.c:

64 /* call out to any extensions interested */
65 for (ext = dpy->ext_procs; ext; ext = ext->next) {
66 if (ext->close_display)
67 (*ext->close_display)(dpy, &ext->codes);
68 }

Members of (*ext):

(gdb) print ext->close_display
$1 = 0xb53c7c80 <glXChannelRectSyncSGIX+13644>
(gdb) print ext->codes
$2 = {extension = 3, major_opcode = 146, first_event = 78, first_error = 167}

Corresponding code (marked line is a place where SIGSEGV is generated):

Dump of assembler code from 0xb53c7c80 to 0xb53c7c8f:
0xb53c7c80 <glXChannelRectSyncSGIX+13644>: push %ebx
0xb53c7c81 <glXChannelRectSyncSGIX+13645>: mov 0x8(%esp),%ebx
0xb53c7c85 <glXChannelRectSyncSGIX+13649>: call 0xb53cb2c4 <glXChannelRectSyncSGIX+27536>
0xb53c7c8a <glXChannelRectSyncSGIX+13654>: cmp 0x34(%eax),%ebx
0xb53c7c8d <glXChannelRectSyncSGIX+13657>: jne 0xb53c7ca0 <glXChannelRectSyncSGIX+13676>
End of assembler dump.

Code that assigns %eax (called from 0xb53c7c85):

(gdb) disas 0xb53cb2c4 0xb53cb2ce
Dump of assembler code from 0xb53cb2c4 to 0xb53cb2ce:
0xb53cb2c4 <glXChannelRectSyncSGIX+27536>: mov 0xb54146c8,%edx
0xb53cb2ca <glXChannelRectSyncSGIX+27542>: mov %gs%edx),%eax
0xb53cb2cd <glXChannelRectSyncSGIX+27545>: ret

(gdb) info line *0xb54146c8
No line number information available for address 0xb54146c8 <_nv000005gl+8>

So it looks like access to non-initialized data

Bugreport is attached

[kir]

What is the status of this issue? should I provide more information or it is clear enough and will be fixed?

[netllama]

I'm not able to reproduce this problem here.

I have a few questions:
0) Does this reproduce if you are not using the Composite extension?
1) Specifically which applications have crashed in this manner?
2) You stated that the crash is random. Can you quantify roughly how frequently you experience these crashes?
3) Does this reproduce if you set RenderAccel to false?

Thanks,
Lonni

[dcontezini]

Here is hapenning the same problem.
It isnt in all programs, just the game i'm working on, that uses a lot of things of Gl.
Have any test that I can do to help you?

[dcontezini]

I dont know why, but it changed where exactly the progarms carshs.
Now its happenning, called by glxChannelRectSyncSGIX(), at XextFindDisplay().
Like before: just after called exit().
I tryed _exit(), anyway, aways the same problem.

[dcontezini]

the problem happens in a call *0x90d0e28(pXExtFindDisplay), by XextFindDisplay, where should have a pointer to a function, and is actually pointing to NULL.
I tested with and without calling SDL_Quit() before exiting, aways getting the same problem.
This pointer pXExtFindDisplay was pointing to a real thing before calling exit, it seens to be any cleaning procedure.

[michael.bauer]

I am able to reproduce this in an simple qt3 test program with the current 9746 driver . I filed a bug report containing a simple test case. Let's see what happens...

// suse 10.1
// 97.46 driver
// Geforce 7800GT
// edit: also reproduced the problem on a Geforce 8800GTS
// edit2: also reproduced for 87.56 driver

[dlehman]

Originally Posted by michael.bauer

I am able to reproduce this in an simple qt3 test program with the current 9746 driver . I filed a bug report containing a simple test case. Let's see what happens...

// suse 10.1
// 97.46 driver
// Geforce 7800GT
// edit: also reproduced the problem on a Geforce 8800GTS
// edit2: also reproduced for 87.56 driver

was there ever a resolution to this issue? i think i have the same problem

thanks