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

[Jamey Sharp]

Yay, data! Thanks.

On Wed, May 5, 2010 at 10:01 AM, The Wanderer <wanderer at fastmail.fm> wrote:
> trace:wgl:wglGetProcAddress func: 'wglGetIntegerv'
> ../../src/xcb_io.c:445: _XReply: Assertion `!dpy->xcb->reply_data' failed.
> 00000019:0000001a: exception code=0x80000101
> Unhandled exception code 0x80000101
> Unknown or malformed query Attached
> 0xf775f430 in ?? ()
> trace: 98 => 80
> Wine-gdb> bt full
> #3  0x7e7a7f44 in _XReply () from /usr/lib32/libX11.so.6
> No symbol table info available.

You were right to type 'frame 3', you're just missing debug symbols.
If you install libx11-6-dbg then you'll be able to get more
information here, including the values of dpy->request and
dpy->last_request_read. Sorry I didn't mention that before.

> #4  0x7d75472f in LnxXextEscape () from /usr/lib32/libatiadlxx.so

I can't find this /usr/lib32/libatiadlxx.so in Debian. Where did it
come from? (I'm not familiar with the fglrx packaging.)

LnxXextEscape had just assembled a minor-opcode 0x40 request when it
called _XReply. That request never made it onto the wire, according to
your xtrace. So there can't have been any buggy callers besides the
minor-opcode 0 that was the last traced request on connection 4. The
only function in libatiadlxx that issues a minor-opcode 0 request is
LnxXextGetDriverData.

My first guess is that you have a 32-bit libatiadlxx.so that does not
match your driver version. If you were to disassemble it I think you'd
find that in LnxXextGetDriverData, _XReply's third argument is some
value smaller than 0x31 (49 decimal). That's the value I see in the
amd64-architecture version of this library, and it's the correct value
for the 228-byte response your xtrace shows. (That parameter is set to
(sizeof(reply)-32)/4.)

I could imagine that AMD stuck some value of type 'long' in this
reply, which would have a different size depending on what
architecture you build for. If that's the case, I don't think you have
any choices but to wait for them to fix it, or run a 32-bit X server.
(Or if you're comfortable with binary-patching your library, set
_XReply's third argument to 0x31, and the assert won't fire any more.
You may have other issues though.) I'd guess that fglrx is not widely
tested with 32-bit clients on 64-bit X servers.

Assuming I've diagnosed this correctly, with a non-XCB build of Xlib,
you wouldn't get an assertion-failure, but that connection would be
out of sync from that point onward, and would fail one way or another
pretty quickly.

I'm reasonably confident in this diagnosis. Either you or the
packagers may want to take this upstream to AMD.

Jamey