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
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
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,
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
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
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
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,
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
reassign 579813 fglrx-driver
thanks
Do what the maintainer wanted to do, Cc'ing control this time.
signature.asc
Description: Digital signature
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.
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
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
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
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
14 matches
Mail list logo
