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

[Patrick Matthäi]

Am 06.05.2010 17:09, schrieb The Wanderer:
> On 05/05/2010 03:21 PM, Jamey Sharp wrote:
>
>> 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.
>
> In hindsight I think you may have, and I certainly do remember checking
> and noticing that I didn't have that particular package installed on
> that machine (though it is on my desktop for a different reason), but I
> apparently didn't remember to install it.
>
>>> #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.)
>
> I suspect that it may have come from a previous manual installation of
> the fglrx driver(s), before I got the Debian packages working properly.
>
> I have now done the following:
>
> mv /usr/lib32/*ati* /root/backups/usr/lib32/
> mv /usr/lib32/*fgl* /root/backups/usr/lib32/
> apt-get install --reinstall fglrx-glx-ia32
>
> and a quick test no longer gives the assertion failure; at a glance,
> everything seems to work fine.

That's good.

>
> There is a specific instruction, in the manual-installation directions
> for the fglrx driver from AMD, to uninstall the existing driver via a
> specific shell script before installing an updated version. I don't
> think I'd found that part of the directions before making the switch
> from the manually-installed driver to the Debian-packaged driver; I
> certainly did not run the script before making the switch.

Then you didn't take care of the manuals ;)

>
> Most likely, by coincidence the necessary libraries from the
> Debian-packaged version had the same ABI as the manually-installed
> version - or at least a compatible one - and so everything continued to
> work at that point.

There is no correct symbol versioning / abi bump within the prop. fglrx 
driver, it is also not meant to build things against it.

>
> If there is any bug in the Debian packages, it would appear to be one of
> incomplete removal of the existing driver. However, while it would
> certainly be nice if installing or updating the Debian package would
> take the necessary steps to properly remove the manually-installed
> driver if one is present, it's not inherently required.
>
> If a previous version of one of these packages did install
> /usr/lib32/libatiadlxx.so (and the other related /usr/lib32 files not
> presently in Debian packages), then there is a bug in that they were not
> removed properly. If no previous version did such a thing, then the
> problem is user error on my part, and there is no actual bug.

It would be a bug, if we remove files not owned by the fglrx package. If 
you are mixing packages^W packages with manual installed sources^W 
binary blobs, you have to take care of it.

>
> Thanks for the help tracking this down; I don't know if I'd have been
> able to narrow it down to the specific files involved on my own without
> a lot more manual work.

If it does not occur again in the next days, I would close this bug, 
much thanks for your effort @jamey and @wanderer.

Cheers.