tag 486507 moreinfo kthxbye On Sat, Oct 4, 2008 at 13:25:17 -0700, Jamey Sharp wrote:
> The locking assertion failures and their associated backtraces should be > looked into, but may be unrelated to the assertion failure that's > actually causing VMWare Server to abort(): > > vmware: ../../src/xcb_lock.c:77: _XGetXCBBuffer: assertion `((int) > ((xcb_req) - (dpy->request)) >= 0)' failed > > First: Could somebody who has encountered this bug please get a stack > trace from the actual assert? > > Does anybody know if VMWare Server is calling Xlib from multiple threads > concurrently? A `thread apply all bt full` in GDB when the assertion > triggers might be informative, especially with libx11-6-dbg installed. > > I suspect this problem would be fixed by the socket handoff work that > Josh and I have been trying to finish for months. If you're willing to > recompile XCB and Xlib yourself, you might try the v2 handoff patch set: > http://lists.freedesktop.org/archives/xcb/2008-March/003392.html > There are some known bugs in that version, but you're unlikely to > encounter them until your app has been running for hours. Unfortunately > the XCB patches don't apply to current upstream git, so you might need > to apply them against commit 7a74ba3d0212f9bfe021d6da9070f71cbc53f85b. > It would be nice to get some feedback on this from the people who can reproduce the issue. This means either getting a backtrace from the failing assert(), with debug packages for libxcb and libx11 installed, or upgrading libx11-6 to the version in experimental, which uses the work mentioned above. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]