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

[Jamey Sharp]

On Mon, May 3, 2010 at 5:19 AM, The Wanderer <wanderer at fastmail.fm> wrote:
> On 05/03/2010 02:04 AM, Jamey Sharp wrote:
>> Hi! Just to be clear, this certainly isn't a bug in libxcb: _XReply
>> is in libx11, not libxcb, and I believe Xlib compiled without XCB
>> support should have failed in this case too.
>
> Does this mean that it could indeed be a Wine bug after all, even though
> they don't call xcb directly? If so, that might justify taking it back
> to them, and seeing if they'll reopen the bug...

It's important to understand that you aren't looking for code that
calls XCB: you're looking for code that calls Xlib.

I can't promise one way or the other whether it's a Wine bug, although
I would guess it isn't. It's more likely to be a bug in a library that
Wine is using, possibly including whatever libGL the fglrx driver
provides, or else an X server bug.

>> We can tell if that's the cause, if you can provide an xtrace or
>> Wireshark dump of the X protocol traffic between the failing
>> application and the server.
>
> I'd be glad to do that, but I've never heard of xtrace, and my only
> experience with Wireshark has been with traffic between two computers.
> I'll see what I can figure out on my own, but any pointers to a how-to
> or the like would be appreciated.

With Wireshark, the key is to get your X connection running over TCP.
You may have to configure your display manager (gdm, kdm, ...) to let
the X server accept TCP connections; then run your application with
DISPLAY=localhost:0. Wireshark can capture the traffic on the loopback
interface then.

Or grab xtrace, which is packaged in Debian, and read its man page.

I wish somebody would write a how-to for this, 'cause I don't have time... :-/

>> The most important other piece of information would be a stack trace
>> from the failing application. That may not actually help, as this
>> assertion can only detect that something went wrong earlier, but it's
>> worth trying anyway.
>
> I've never even heard of a stack trace from a failed assertion, and I
> certainly don't have one in this case.

In general, if you normally run 'foo -v quux', try 'gdb --args foo -v
quux' instead, then 'run'. After the assertion fails, type 'bt full'
and send the resulting output. This is a lot more useful if you have
libbaz-dbg installed for every libbaz used by your application. At
least libx11-6-dbg would be a good start.

However, Wine may have or require special ways to attach a debugger. I
don't know.

> I do have an 'strace -f' log of a
> run in which this failure occurred, but I suspect that's not going to be
> useful.

Yeah, I don't think I could get enough out of the read syscalls to
replace the protocol trace, and I don't think I want to try. :-)

Jamey