Yay, data! Thanks. On Wed, May 5, 2010 at 10:01 AM, The Wanderer <wande...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
