[Pkg-fglrx-devel] Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy->xcb->reply_data' failed.

[Jamey Sharp]

On Tue, May 4, 2010 at 6:54 AM, The Wanderer <wanderer at fastmail.fm> wrote:
> I actually did this yesterday, shortly before leaving for work. Attached
> please find the result of
>
> xtrace /tmp/wow &> /tmp/wow-winedebug-try3

Thanks, that's a start. It's hard to tell exactly what's going on
though, because apparently there are five different X connections
involved, and probably several processes. Maybe asking xtrace for
timestamps would help. Still, it looks like these messages go
together:

004:<:0008: 12: ATIFGLEXTENSION-Request(140,7): UNKNOWN ...
004:>:0008:1232: unexpected Reply: data1=0x01 data2=0x00 unparsed-data=...
004:<:0009: 12: ATIFGLEXTENSION-Request(140,0): UNKNOWN ...
004:>:0009:228: unexpected Reply: data1=0x01 data2=0x00 unparsed-data=...
../../src/xcb_io.c:445: _XReply: Assertion `!dpy->xcb->reply_data' failed.
err:module:attach_process_dlls "opengl32.dll" failed to initialize, aborting

This is the only connection that issued a minor-opcode 0 request,
which apparently is FGLGetDriverData, but another connection issued
several minor-opcode 7 requests, and continued processing responses
fine afterwards. I can't find any public information on
ATIFGLEXTENSION minor opcodes higher than 6, so I can't decode that or
guess what it means.

I'm wondering if there are two (or more) different functions in
FGLRX's libGL that all issue this minor opcode 7, and maybe one of
them does it wrong.

By the way, the connection that issued the above requests does not
seem to have respected your WINEDEBUG="+synchronous" setting. Dunno
what that means, though it might just be it died before it could sync
the first time.

> I'm familiar with doing that (well, 'gdb foo' and 'run -v quux'), but I
> could have sworn that last time I tried it on a failed assertion, the
> 'bt full' returned no information, because the running program had
> already exited because of the failed assertion.

No, assert calls abort(), which kills the current process with
SIGABRT, which GDB traps before the process actually exits.

Of course if this application is forking, it can be quite tricky to
get gdb attached to the process that actually dies. It may be easier
to run `ulimit -c unlimited` to enable core dumps, then let the
application die, then use `gdb -c` to inspect the coredump.

When you have the failed process in GDB, it would also help to go to
the _XReply stack frame and print dpy->request and
dpy->last_request_read. I'm guessing those will be 9 and 8,
respectively.

A stack trace would be useful for confirming my hypothesis that the
failure is being detected while looking for the FGLGetDriverData
reply. If nothing else I can disassemble _XReply's caller and maybe
spot a problem that way (ugh, hate binary-only drivers). Of course a
minimal test case would help a lot here, and knowing what function is
running when this fails may help you find simpler application that
fails the same way.

Hey, does `glxinfo` assert-fail for you?

Jamey