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 <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.
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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
