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

The Wanderer wanderer at fastmail.fm
Wed May 5 14:40:11 UTC 2010


On 05/04/2010 02:40 PM, Jamey Sharp wrote:

> On Tue, May 4, 2010 at 6:54 AM, The Wanderer <wanderer at fastmail.fm>
> wrote:

>> 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.

I tried that, both with running the shell-script wrapper and with
running its commands by hand (just in case the ulimit setting was
getting lost somewhere), and no core file seems to have been produced in
any obvious location. I've checked /tmp, the current directory, and the
directory with the executable being run by Wine, with no luck.

I tried just running Wine under gdb, in case it would in fact catch the
correct process; it did catch the signal after the assert, but 'bt full'
just reported a series of

#0  0x12345678 in ?? ()
No symbol table info available

which obviously isn't very useful.

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

No. The only thing which assert-fails for me, that I've tried so far, is
Wine, and that only (as far as I can tell) when trying to use OpenGL.





More information about the Pkg-fglrx-devel mailing list