synergyc dies with xcb_lock.c assertion failed

[Aaron Kurtz]

Binary package hint: synergy

synergy 1.3.1-4ubuntu2 on 8.10

Every so often, client dies, doesn't restart.
When I run it as synergyc -f SERVER, it ends with

INFO: CScreen.cpp,98: entering screen
DEBUG: CServerProxy.cpp,523: recv clipboard 0 size=60
synergyc: ../../src/xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy->request)) >= 0)' failed.
Aborted

[Martin Olsson (mnemo)]

I'm also seeing this all the time. Happens about every hour or so. This is probably the most annoying bug I have in intrepid right now. At least I've been able to get a full stack leading up to this particular assert:

#1 0xb7e04a25 in _XGetXCBBuffer (dpy=0x8ec27b0) at ../../src/xcb_lock.c:101
#2 0xb7e05e83 in _XSend (dpy=0x8ec27b0, data=0x0, size=0) at ../../src/xcb_io.c:239
#3 0xb7e06042 in _XFlush (dpy=0x8ec27b0) at ../../src/xcb_io.c:258
#4 0xb7dde041 in XFlush (dpy=0x8ec27b0) at ../../src/Flush.c:41
#5 0x080ec3ac in CXWindowsEventQueueBuffer::flush (this=0x8ed7820) at CXWindowsEventQueueBuffer.cpp:249
#6 0x080ec4e3 in CXWindowsEventQueueBuffer::addEvent (this=0x8ed7820, dataID=11) at CXWindowsEventQueueBuffer.cpp:210
#7 0x0811f124 in CEventQueue::addEvent (this=0xbfd24a3c, event=@0xb72e8140) at CEventQueue.cpp:221
#8 0x081180be in CTCPSocket::sendEvent (this=0x8ed8030, type=19) at CTCPSocket.cpp:358
#9 0x08118512 in CTCPSocket::serviceConnected (this=0x8ed8030, job=0xb69118a8, read=false, write=true, error=false) at CTCPSocket.cpp:465
#10 0x0811a785 in TSocketMultiplexerMethodJob<CTCPSocket>::run (this=0xb69118a8, read=false, write=true, error=false)
    at TSocketMultiplexerMethodJob.h:79
#11 0x08112d09 in CSocketMultiplexer::serviceThread (this=0xbfd24adc) at CSocketMultiplexer.cpp:228
#12 0x081146c3 in TMethodJob<CSocketMultiplexer>::run (this=0x8ec2090) at ../../lib/base/TMethodJob.h:63
#13 0x0811d908 in CThread::threadFunc (vjob=0x8ec2090) at CThread.cpp:152
#14 0x08132845 in CArchMultithreadPosix::doThreadFunc (this=0x8ec0008, thread=0x8ec20c8) at CArchMultithreadPosix.cpp:720
#15 0x081329ad in CArchMultithreadPosix::threadFunc (vrep=0x8ec20c8) at CArchMultithreadPosix.cpp:701
#16 0xb7c8950f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#17 0xb7c067ee in clone () from /lib/tls/i686/cmov/libc.so.6

#1 0xb7e04a25 in _XGetXCBBuffer (dpy=0x8ec27b0) at ../../src/xcb_lock.c:101
 xcb_req = 57886
 dummy_request = {reqType = 0 '\0', data = 0 '\0', length = 0}
 __PRETTY_FUNCTION__ = "_XGetXCBBuffer"
#2 0xb7e05e83 in _XSend (dpy=0x8ec27b0, data=0x0, size=0) at ../../src/xcb_io.c:239
 c = (xcb_connection_t *) 0x8ec2fc0
 __PRETTY_FUNCTION__ = "_XSend"
#3 0xb7e06042 in _XFlush (dpy=0x8ec27b0) at ../../src/xcb_io.c:258
No locals.
#4 0xb7dde041 in XFlush (dpy=0x8ec27b0) at ../../src/Flush.c:41
No locals.
#5 0x080ec3ac in CXWindowsEventQueueBuffer::flush (this=0x8ed7820) at CXWindowsEventQueueBuffer.cpp:249
No locals.
#6 0x080ec4e3 in CXWindowsEventQueueBuffer::addEvent (this=0x8ed7820, dataID=11) at CXWindowsEventQueueBuffer.cpp:210
 xevent = {type = 33, xany = {type = 33, serial = 3073278116, send_event = -1076737408, display = 0x7d07, window = 48234500}, xkey = {
    type = 33, serial = 3073278116, send_event = -1076737408, display = 0x7d07, window = 48234500, root = 485, subwindow = 32, time = 11, x = 0,
    y = 0, x_root = 0, y_root = 0, state = 0, keycode = 0, same_screen = 0}, xbutton = {type = 33, serial = 3073278116, send_event = -1076737408,
    display = 0x7d07, window = 48234500, root = 485, subwindow = 32, time = 11, x = 0, y = 0, x_root = 0, y_root = 0, state = 0, button = 0,
    same_screen = 0}, xmotio...

[Martin Olsson (mnemo)]

The actual assert (in package libx11-xcb1) contains a macro, so in the code is looks like this:
assert(XCB_SEQUENCE_COMPARE(xcb_req, >=, dpy->request));

I don't know enough about XCB to figure out what to make of that.

[Martin Olsson (mnemo)]

I modified the code around the assert to say:

    /* if Xlib has a partial request pending then XCB doesn't know about
     * the current request yet */
    if(dpy->xcb->partial_request) {
        ++xcb_req;
        printf ("partial request thing\n");
    }
    if (XCB_SEQUENCE_COMPARE(xcb_req, <, dpy->request)) {
        printf ("xcb_req=%u\n", xcb_req);
        printf ("dpy->request=%u\n", dpy->request);
        print_backtrace();
        fflush(stdout);
    }
    assert(XCB_SEQUENCE_COMPARE(xcb_req, >=, dpy->request));
    dpy->request = xcb_req;

And then it prints:
xcb_req=3334
dpy->request=3335

So basically, this means that the code near when the assert is triggered does NOT take the branch into the "++xcb_req" statement. I've no idea if it is supposed to do that or not but that would certainly have prevented the assert from being hit?

[Martin Olsson (mnemo)]

The upstream bug report is about the same assert being hit in the synergy server (I'm linking it even though both me and aaron is hitting the assert in the synergy client).

[Martin Olsson (mnemo)]

It seems Debian is also plagued by this bug (not that surprising but):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504654

[Anton Blanchard (anton-samba)]

I've been hitting this bug regularly and I agree its pretty annoying.

The synergy X11 backend claims to only make Xlib calls from the main thread:

// NOTE -- the X display is shared among several objects but is owned
// by the CXWindowsScreen. Xlib is not reentrant so we must ensure
// that no two objects can simultaneously call Xlib with the display.
// this is easy since we only make X11 calls from the main thread.

This is not true, for example we call Xflush() from multiple threads:

synergyc(CXWindowsEventQueueBuffer::flush()+0x55) synergyc(CXWindowsEventQueueBuffer::waitForEvent(double)+0x60)
synergyc(CEventQueue::getEvent(CEvent&, double)+0x157)
synergyc
synergyc(main+0x13d)

and:

synergyc(CXWindowsEventQueueBuffer::flush()+0x55)
synergyc(CXWindowsEventQueueBuffer::addEvent(unsigned int)+0x82)
synergyc(CEventQueue::addEvent(CEvent const&)+0x72)
synergyc(CTCPSocket::sendEvent(unsigned int)+0x55)
synergyc(CTCPSocket::serviceConnected(ISocketMultiplexerJob*, bool, bool, bool)+0x16f)
synergyc(TSocketMultiplexerMethodJob<CTCPSocket>::run(bool, bool, bool)+0x5b)
synergyc(CSocketMultiplexer::serviceThread(void*)+0x2d1)
synergyc(TMethodJob<CSocketMultiplexer>::run()+0x2a)
synergyc(CThread::threadFunc(void*)+0x76)
synergyc(CArchMultithreadPosix::doThreadFunc(CArchThreadImpl*)+0x50)
synergyc(CArchMultithreadPosix::threadFunc(void*)+0x42)
/lib/tls/i686/cmov/libpthread.so.0
/lib/tls/i686/cmov/libc.so.6(clone+0x5e)

I'm not an Xlib expert, but it appears that we need to call XInitThreads() if we multiple threads call into Xlib. The following patch does that, and I haven't seen the fail with it applied in a few hours (usually fails in 30 minutes).

[Aaron Kurtz (a.kurtz)]

Thanks for the patch Anton. I was experiencing failures on the order of every 5 minutes,
and I haven't had a crash yet after applying it.

I've created PPA builds of synergy with the patch applied for anyone else suffering from this.

https://launchpad.net/~a.kurtz/+archive

[Brian Murray (brian-murray)]

Looking at the attachments in this bug report, I noticed that "synergy_XInitThreads.patch" was not flagged as a patch. A patch contains changes to an Ubuntu package that will resolve a bug and this attachment is one! Subsequently, I've checked the patch flag for it. In the future when submitting patches please use the patch checkbox as there are some Launchpad searches that use this feature. Thanks for your contribution Anton Blanchard!

[Cyrion (tolk-inn)]

Thanks a lot Anton & Aaron, this patch works perfectly for me - no more synergyc seg faults.
Damien.

[Launchpad Janitor (janitor)]

This bug was fixed in the package synergy - 1.3.1-5ubuntu2

---------------
synergy (1.3.1-5ubuntu2) jaunty; urgency=low

  * Call to XInitThreads() needed; prevents frequent crashes. (LP: #299152)
    - Patch taken from debian; applied inline.
    - debian/ubuntu-applied-patches/call_xinitthreads.patch

 -- Andreas Wenning <email address hidden> Sun, 19 Apr 2009 18:55:53 +0200