Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
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. 0019:001a: exception code=0x8101 Unhandled exception code 0x8101 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. 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. 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. 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. 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579813: [Pkg-fglrx-devel] Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
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. 0019:001a: exception code=0x8101 Unhandled exception code 0x8101 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
Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
On 05/04/2010 02:40 PM, Jamey Sharp wrote: On Tue, May 4, 2010 at 6:54 AM, The Wanderer wande...@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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
On 05/04/2010 02:40 PM, Jamey Sharp wrote: 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've been doing some more fiddling with this, and I managed to get a viable stack trace using winedbg; see attached. (It should be a lot smaller than the last attachment. Is there any easy way to prevent attachments from being displayed inline that way when they're so big?) I also included a register dump, just in case that would be useful. Looking at the dump now, though, I'm suddenly no longer sure that it was taken at the correct stack frame; take it with a grain of salt. I can re-run the debug session if necessary. When you have the failed process in GDB, it would also help to go to the _XReply stack frame and print dpy-request and dpy-last_request_read. I'm guessing those will be 9 and 8, respectively. Unfortunately, I was not able to manage this. Possibly I don't understand how to go to the_XReply stack frame; I tried both 'select-frame 3' and 'frame 3' (the latter of which did print '#3 0x7e7a7f44 in _XReply () from /usr/lib32/libX11.so.6'), but both ways, I got only 'No symbol dpy in current context. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
On 05/05/2010 11:43 AM, The Wanderer wrote:
On 05/04/2010 02:40 PM, Jamey Sharp wrote:
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've been doing some more fiddling with this, and I managed to get a
viable stack trace using winedbg; see attached.
Really attached this time. I cut the lines from my failed attempts at
getting other info out of the log, since they weren't helpful and had a
bunch of garbage characters from backspacing and the like.
0019:001a: create process 'C:\Program Files\World of Warcraft\Wow.exe'/0x110738
@0x401000 (00)
0019:001a: create thread I @0x401000
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
0019:001a: loads DLL C:\windows\system32\KERNEL32.dll @0x7ede (00)
0019:001a: loads DLL C:\windows\system32\ntdll.dll @0x7ef6 (00)
0019:001a: loads DLL C:\Program Files\World of Warcraft\DivxDecoder.dll
@0x1000 (00)
0019:001a: loads DLL C:\windows\system32\rpcrt4.dll @0x7e96 (00)
0019:001a: loads DLL C:\windows\system32\advapi32.dll @0x7e9d (00)
0019:001a: loads DLL C:\windows\system32\gdi32.dll @0x7ea3 (00)
0019:001a: loads DLL C:\windows\system32\user32.dll @0x7eac (00)
0019:001a: loads DLL C:\windows\system32\winmm.dll @0x7ebe (00)
0019:001a: loads DLL C:\windows\system32\opengl32.dll @0x7e8d (00)
0019:001a: loads DLL C:\windows\system32\imm32.dll @0x7e65 (00)
0019:001a: loads DLL C:\windows\system32\mpr.dll @0x7e5c (00)
0019:001a: loads DLL C:\windows\system32\shlwapi.dll @0x7e57 (00)
0019:001a: loads DLL C:\windows\system32\comctl32.dll @0x7e2d (00)
0019:001a: loads DLL C:\windows\system32\shell32.dll @0x7e3a (00)
0019:001a: loads DLL C:\windows\system32\wininet.dll @0x7e60 (00)
0019:001a: loads DLL C:\windows\system32\msacm32.dll @0x7e2a (00)
0019:001a: loads DLL C:\windows\system32\ws2_32.dll @0x7e28 (00)
0019:001a: loads DLL C:\windows\system32\ole32.dll @0x7e14 (00)
0019:001a: loads DLL C:\windows\system32\dinput.dll @0x7e23 (00)
0019:001a: loads DLL C:\windows\system32\dinput8.dll @0x7e26 (00)
0019:001a: loads DLL C:\windows\system32\winspool.drv @0x7e0a (00)
0019:001a: loads DLL C:\windows\system32\lz32.dll @0x7e09 (00)
0019:001a: loads DLL C:\windows\system32\version.dll @0x7ef4 (00)
0019:001a: loads DLL C:\windows\system32\setupapi.dll @0x7e0d (00)
0019:001a: loads DLL C:\windows\system32\hid.dll @0x7e07 (00)
0019:001a: loads DLL C:\windows\system32\winex11.drv @0x7ded (00)
fixme:dbghelp_dwarf:compute_location Only supporting one breg (18 - 24)
trace:wgl:wglGetProcAddress func: 'wglGetIntegerv'
../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
0019:001a: exception code=0x8101
Unhandled exception code 0x8101
Unknown or malformed query Attached
0xf775f430 in ?? ()
trace: 98 = 80
Wine-gdb bt full
#0 0xf775f430 in ?? ()
No symbol table info available.
#1 0xf74bbb72 in *__GI_abort () at abort.c:88
act = {__sigaction_handler = {sa_handler = 0x3a74d0, sa_sigaction =
0x3a74d0}, sa_mask = {__val = {4149211453, 104, 80, 3831232, 3831020, 104, 80,
76, 2087318208, 4150058996, 76, 75, 3831192,
4149142594, 2087318216, 76, 3831232, 2087318216, 0, 4222451712,
2087318216, 2087318216, 2087318216, 2087318216, 2087318291, 2087318316,
2087318216, 2087318316, 0, 0, 0, 0}}, sa_flags = 0,
sa_restorer = 0xb}
sigs = {__val = {32, 0 repeats 31 times}}
#2 0xf74b168e in *__GI___assert_fail (assertion=0x7e8151d9
!dpy-xcb-reply_data, file=0x7e815189 ../../src/xcb_io.c, line=445,
function=0x7e8152f8 _XReply) at assert.c:78
buf = 0x7c69f2c8 (\363i|\360\363\\\367c/xcb_io.c:445: _XReply:
Assertion `!dpy-xcb-reply_data' faileP
#3 0x7e7a7f44 in _XReply () from /usr/lib32/libX11.so.6
No symbol table info available.
#4 0x7d75472f in LnxXextEscape () from /usr/lib32/libatiadlxx.so
No symbol table info available.
#5 0x7d733935 in Send () from /usr/lib32/libatiadlxx.so
No symbol table info available.
#6 0x7d747a81 in Pack_DI_AdapterCaps_Get () from /usr/lib32/libatiadlxx.so
No symbol table info available.
#7 0x7d73c458 in ADL_Workstation_AdapterNumOfGLSyncConnectors_Get () from
/usr/lib32/libatiadlxx.so
No symbol table info available.
#8 0x7b873603 in ?? () from /usr/lib32/dri/fglrx_dri.so
No symbol table info available.
Wine-gdb info all-registers
eax0x0 0
ecx
Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
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. 0019:001a: exception code=0x8101 Unhandled exception code 0x8101 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
Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
On Tue, May 4, 2010 at 6:54 AM, The Wanderer wande...@fastmail.fm wrote: I actually did this yesterday, shortly before leaving for work. Attached please find the result of xtrace /tmp/wow /tmp/wow-winedebug-try3 Thanks, that's a start. It's hard to tell exactly what's going on though, because apparently there are five different X connections involved, and probably several processes. Maybe asking xtrace for timestamps would help. Still, it looks like these messages go together: 004::0008: 12: ATIFGLEXTENSION-Request(140,7): UNKNOWN ... 004::0008:1232: unexpected Reply: data1=0x01 data2=0x00 unparsed-data=... 004::0009: 12: ATIFGLEXTENSION-Request(140,0): UNKNOWN ... 004::0009:228: unexpected Reply: data1=0x01 data2=0x00 unparsed-data=... ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed. err:module:attach_process_dlls opengl32.dll failed to initialize, aborting This is the only connection that issued a minor-opcode 0 request, which apparently is FGLGetDriverData, but another connection issued several minor-opcode 7 requests, and continued processing responses fine afterwards. I can't find any public information on ATIFGLEXTENSION minor opcodes higher than 6, so I can't decode that or guess what it means. I'm wondering if there are two (or more) different functions in FGLRX's libGL that all issue this minor opcode 7, and maybe one of them does it wrong. By the way, the connection that issued the above requests does not seem to have respected your WINEDEBUG=+synchronous setting. Dunno what that means, though it might just be it died before it could sync the first time. 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. When you have the failed process in GDB, it would also help to go to the _XReply stack frame and print dpy-request and dpy-last_request_read. I'm guessing those will be 9 and 8, respectively. A stack trace would be useful for confirming my hypothesis that the failure is being detected while looking for the FGLGetDriverData reply. If nothing else I can disassemble _XReply's caller and maybe spot a problem that way (ugh, hate binary-only drivers). Of course a minimal test case would help a lot here, and knowing what function is running when this fails may help you find simpler application that fails the same way. Hey, does `glxinfo` assert-fail for you? Jamey -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
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. But maybe it's just as well you assigned it to libxcb1 (however briefly) so that I'd notice it. Another instance of this symptom was a server bug: https://bugzilla.redhat.com/show_bug.cgi?id=417821 That was a bug squashed in the X.org implementation of GLX sometime in the 6.8 series, but the broken code has lingered in other places. 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. 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. This assertion means that some extension library (could be libGL, I don't know) didn't finish reading the last response from the server before asking for the next one. Before XCB, that kind of failure should have permanently mangled the X connection, unless I've missed some magic recovery mechanism Xlib had for covering up bugs (which has happened before). Hope this helps, Jamey -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
reassign 579813 fglrx-driver thanks Do what the maintainer wanted to do, Cc'ing control this time. signature.asc Description: Digital signature
Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
On Mon, May 3, 2010 at 5:19 AM, The Wanderer wande...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
reassign 579813 fglrx-driver thanks Actually, no; the reason I thought it might be an fglrx bug is because in the reports I found from when this error message was prevalent, it was specifically described as being not an xcb bug but a bug in the calling application. According to Wine, they don't call xcb directly, so it has to be elsewhere in the stack, they think in GLX; as far as I know, that's provided by the graphics driver, in this case fglrx. That would make fglrx the calling application, and thus the presumptive cause of the error. as a point of reference, i am able to run world of warcraft on fglrx 10-4 without issue. i just noticed that you have a bunch off fglrx (EE) errors in your Xorg.log. those could be a clue on your problems. you should try to resolve those first. mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579813: [Pkg-fglrx-devel] Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
reassign libxcb1 thanks On Fri, 30 Apr 2010 21:54:18 -0400 The Wanderer wrote: I should start out by saying that I am not 100% certain that this bug is in fglrx-driver; it also might be in libxcb, in Wine, or somewhere (else) in the OpenGL or GLX stack, or even in X. I am reporting it under fglrx-driver because I have to pick some package, and fglrx seems the most likely candidate. I track stable and testing. Fairly recently, I noticed that the fglrx-* packages could now be updated without needing to remove xserver-xorg*, and ran a partial dist-upgrade (omitting packages which have active bugs unless I can specifically determine that they don't affect me). In the process, both fglrx-driver and libxcb* were updated. After the update, I attempted to launch World of Warcraft under Wine. Instead of launching successfully (as it had been doing before the update), it exited before really getting started, with only the following console output: == ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed. err:module:attach_process_dlls opengl32.dll failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for LC:\\Program Files\\World of Warcraft\\Wow.exe failed, status 8101 == i don't really see how this could be a fglrx bug. the error refers to opengl.dll, which probably lead to your conclusions, but that is provided by wine; not fglrx. libxcb appears to have gone through quite a few changes recently, and my best guess is that the problem was introduced there. the latest fglrx is 10-4, and you could try upgrading, but it probably won't make a difference. can you reproduce the problem with the free radeon driver? mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579813: [Pkg-fglrx-devel] Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
Michael Gilbert michael.s.gilb...@gmail.com (02/05/2010): reassign libxcb1 thanks Please Cc the maintainers of the package you're reassiging to. They don't get your message otherwise, which some might consider impolite. signature.asc Description: Digital signature
Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
Package: fglrx-driver Version: 1:10-3~prerelease-3 Severity: normal I should start out by saying that I am not 100% certain that this bug is in fglrx-driver; it also might be in libxcb, in Wine, or somewhere (else) in the OpenGL or GLX stack, or even in X. I am reporting it under fglrx-driver because I have to pick some package, and fglrx seems the most likely candidate. I track stable and testing. Fairly recently, I noticed that the fglrx-* packages could now be updated without needing to remove xserver-xorg*, and ran a partial dist-upgrade (omitting packages which have active bugs unless I can specifically determine that they don't affect me). In the process, both fglrx-driver and libxcb* were updated. After the update, I attempted to launch World of Warcraft under Wine. Instead of launching successfully (as it had been doing before the update), it exited before really getting started, with only the following console output: == ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed. err:module:attach_process_dlls opengl32.dll failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for LC:\\Program Files\\World of Warcraft\\Wow.exe failed, status 8101 == Googling on the assertion message produced numerous reports of a similar error (with a different, but consistent, line number) back in about 2008, which had apparently been caused by a change in the default locking behavior of xcb, triggering a formerly hidden bug in programs which had not been handling locking properly. Those reports mentioned that many different programs would produce the same error, including both OpenOffice.org Writer and glxgears. However, I am able to run both oowriter and glxgears without this error. The only thing I have found which produces this error is Wine. I have, however, been able to reproduce the problem (later in execution) with programs other than World of Warcraft. I therefore reported this as Wine bug 22490. The bug was closed as invalid in fairly short order, on the grounds that since Wine does not directly call libxcb, this cannot be a a Wine issue. It was suggested that I run Wine with 'WINEDEBUG=+synchronous,+wgl' in an attempt to obtain more information; however, doing so provided only the same console output as before. Grasping at straws, I obtained an strace log of the failing session, but it does not appear to contain any really usable information. I have considered attempting to downgrade fglrx-driver and/or the libxcb packages in order to narrow down the apparent location of this bug. However, doing so would not be a trivial matter, as downgrading either would effectively require me to also downgrade X; additionally, from the difficulty I have had with even installing or upgrading fglrx to date (having lost X temporarily almost every time), I am decidedly hesitant to attempt to downgrade it. As of yet, I have not been able to find any hints online that other people are experiencing this same issue. Whether this is because few people have both installed the updated versions of the packages involved and attempted to run something under Wine, or because there is something unusual about my own system, is not clear. What information can I provide which will help narrow down the location and/or cause of this bug, and how can I obtain that information? -- Package-specific info: VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: ATI Technologies Inc M92 [Mobility Radeon HD 4500 Series] DRM and fglrx Informations from dmesg: [0.00] No AGP bridge found [0.423163] Linux agpgart interface v0.103 [4.213257] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel. [4.256333] [fglrx] Maximum main memory to use for locked dma buffers: 3771 MBytes. [4.256867] [fglrx] vendor: 1002 device: 9553 count: 1 [4.257443] [fglrx] ioport: bar 1, base 0x2000, size: 0x100 [4.258013] [fglrx] Kernel PAT support is enabled [4.258223] [fglrx] module loaded - fglrx 8.72.10 [Mar 11 2010] with 1 minors [ 313.526469] fglrx_pci :01:00.0: irq 32 for MSI/MSI-X [ 313.526968] [fglrx] Firegl kernel thread PID: 2806 [ 313.527146] [fglrx] IRQ 32 Enabled [ 313.832462] [fglrx] Gart USWC size:1228 M. [ 313.832465] [fglrx] Gart cacheable size:487 M. [ 313.832470] [fglrx] Reserved FB block: Shared offset:0, size:100 [ 313.832472] [fglrx] Reserved FB block: Unshared offset:fc27000, size:3d9000 [ 313.832474] [fglrx] Reserved FB block: Unshared offset:1fffb000, size:5000 Xorg X server configuration file status: -rw-r--r-- 1 root root 1357 Apr 23 20:58 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: #Section Monitor # Identifier aticonfig-Monitor[0]-0 # Option VendorName ATI Proprietary Driver # Option ModelName Generic Autodetecting Monitor # Option DPMS true #EndSection # EDID version 1 revision 3 Section
