Bug#495498: xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy-request)) = 0)' failed.
Any progress yet? Things I can test? I noticed that you are using threads in synergys. The assertion that we run into can be caused if multiple threads do calls to GUI calls (X, Xt). All such calls must be done from one thread. Are you doing X calls from more than one thread? -- Carlo Wood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495498: xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy-request)) = 0)' failed.
Carlo Wood wrote: Any progress yet? Things I can test? Nope, sorry. I probably won't have much to report for a while; day job interferes. I noticed that you are using threads in synergys. The assertion that we run into can be caused if multiple threads do calls to GUI calls (X, Xt). All such calls must be done from one thread. Are you doing X calls from more than one thread? I'm not entirely sure. If you look at the history of the package, the most recent upload was done to fix a problem in synergyc that was somewhat related, in that xcb seemed to trigger it. The problem there was that we were noticing events from watching the X socket. The problem is that X events could sneak through due to a race condition, and the client would appear to hang. For that problem, the client didn't do anything thread-unsafe with X calls, but it did detect events and handle them in separate threads. I suspect something similar may be happening in the server, but have no idea if that's causing this or some other problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495498: xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy-request)) = 0)' failed.
Ok, I made some progress myself. I read a lot of pages that Google returns for this assertion and it seemed to point to libxcb; not that that library contains a bug, but because it is related and because it was made more strict. Anyways, I joined there IRC channel and got some help from Julien Danjou (jd_) who suggested to add XSynchronize(display, 1) before the line '// verify the availability of the XTest extension' in lib/platform/CXWindowsScreen.cpp (around line 847). The result would be that things go wrong at the moment of the bad call, and not later giving me different stack traces all the time. However, the result isn't an assertion anymore. It is a dead lock. And that is pretty logical if you think about it: this bug is clearly a race condition. It turns out that indeed two different threads are calling XSync at the same time. I see the following two backtraces: (gdb) thread 3 [Switching to thread 3 (Thread 0x41ebc950 (LWP 24059))]#0 0x7f8000120d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x7f8000120d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x7f7fff7ad8bb in _xcb_lock_io () from /usr/lib/libxcb.so.1 #2 0x7f7fff9c0a09 in xcb_xlib_lock () from /usr/lib/libxcb-xlib.so.0 #3 0x7f8000b3b59a in condition_wait (dpy=0x27103a0, cv=0x2770fb8) at ../../src/xcb_io.c:76 #4 0x7f8000b3b8c4 in process_responses (dpy=0x27103a0, wait_for_first_event=0, current_error=0x41ebaa60, current_request=7465) at ../../src/xcb_io.c:151 #5 0x7f8000b3c141 in _XReply (dpy=0x27103a0, rep=0x41ebaab0, extra=0, discard=1) at ../../src/xcb_io.c:370 #6 0x7f8000b2a7f8 in XSync (dpy=0x27103a0, discard=0) at ../../src/Sync.c:48 #7 0x7f8000b2a8da in _XSyncFunction (dpy=0x2712234) at ../../src/Synchro.c:37 #8 0x7f8000b26d46 in XSendEvent (dpy=0x27103a0, w=18874372, propagate=0, event_mask=0, event=0x2760320) at ../../src/SendEvent.c:82 #9 0x00464633 in CXWindowsEventQueueBuffer::flush (this=0x272ec10) at ../../../synergy/lib/platform/CXWindowsEventQueueBuffer.cpp:247 #10 0x004647c6 in CXWindowsEventQueueBuffer::addEvent (this=0x272ec10, dataID=5) at ../../../synergy/lib/platform/CXWindowsEventQueueBuffer.cpp:210 #11 0x0049a531 in CEventQueue::addEvent (this=0x7fff09a7a8b0, [EMAIL PROTECTED]) at ../../../synergy/lib/base/CEventQueue.cpp:221 #12 0x00492cb2 in CTCPSocket::sendEvent (this=0x276aea0, type=38) at ../../../synergy/lib/net/CTCPSocket.cpp:358 #13 0x004930c7 in CTCPSocket::serviceConnected (this=0x276aea0, job=0x276cff0, read=false, write=true, error=false) at ../../../synergy/lib/net/CTCPSocket.cpp:465 #14 0x0049549d in TSocketMultiplexerMethodJobCTCPSocket::run (this=0x276cff0, read=false, write=true, error=false) at ../../../synergy/lib/net/TSocketMultiplexerMethodJob.h:79 #15 0x0048d1e1 in CSocketMultiplexer::serviceThread (this=0x7fff09a7a9f0) at ../../../synergy/lib/net/CSocketMultiplexer.cpp:228 #16 0x0048ef2d in TMethodJobCSocketMultiplexer::run (this=0x2711f70) at ../../../synergy/lib/base/TMethodJob.h:63 #17 0x00498b57 in CThread::threadFunc (vjob=0x2711f70) at ../../../synergy/lib/mt/CThread.cpp:152 ... while thread 1 is: (gdb) bt #0 0x7f8000123394 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x7f8000121270 in pthread_cond_broadcast@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x7f7fff9c0ac2 in xcb_xlib_unlock () from /usr/lib/libxcb-xlib.so.0 #3 0x7f8000b3b550 in condition_wait (dpy=0x27103a0, cv=0x2770fb8) at ../../src/xcb_io.c:74 #4 0x7f8000b3b8c4 in process_responses (dpy=0x27103a0, wait_for_first_event=0, current_error=0x7fff09a7a380, current_request=7466) at ../../src/xcb_io.c:151 #5 0x7f8000b3c141 in _XReply (dpy=0x27103a0, rep=0x7fff09a7a3d0, extra=0, discard=1) at ../../src/xcb_io.c:370 #6 0x7f8000b2a7f8 in XSync (dpy=0x27103a0, discard=0) at ../../src/Sync.c:48 #7 0x7f8000b2a8da in _XSyncFunction (dpy=0x2712230) at ../../src/Synchro.c:37 #8 0x7f8000b21967 in XQueryPointer (dpy=0x27103a0, w=315, root=0x7fff09a7a4e8, child=0x7fff09a7a4e0, root_x=0x7fff09a7a4dc, root_y=0x7fff09a7a4d8, win_x=0x7fff09a7a4d4, win_y=0x7fff09a7a4d0, mask=0x7fff09a7a4cc) at ../../src/QuPntr.c:64 #9 0x0046771d in CXWindowsKeyState::pollActiveModifiers (this=0x2729720) at ../../../synergy/lib/platform/CXWindowsKeyState.cpp:141 #10 0x00484a3b in CPlatformScreen::pollActiveModifiers (this=0x2710190) at ../../../synergy/lib/synergy/CPlatformScreen.cpp:93 #11 0x004880b6 in CScreen::pollActiveModifiers (this=0x2711ee0) at ../../../synergy/lib/synergy/CScreen.cpp:397 #12 0x00432b01 in CPrimaryClient::getToggleMask (this=0x272ee00) at ../../../synergy/lib/server/CPrimaryClient.cpp:89 #13 0x00437c3c in CServer::switchScreen (this=0x272f860, dst=0x272ee00, x=3355, y=672, forScreensaver=false) at
Bug#495498: xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy-request)) = 0)' failed.
In a next run, I *did* get an assertion though... DEBUG1: ../../../synergy/lib/server/CClientProxy1_0.cpp,261: send leave to taryn synergys: ../../src/xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy-request)) = 0)' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x7f8bd2a676f0 (LWP 25294)] 0x7f8bd0e0def5 in raise () from /lib/libc.so.6 (gdb) bt #0 0x7f8bd0e0def5 in raise () from /lib/libc.so.6 #1 0x7f8bd0e0f413 in abort () from /lib/libc.so.6 #2 0x7f8bd0e06dc9 in __assert_fail () from /lib/libc.so.6 #3 0x7f8bd1b53740 in _XGetXCBBuffer (dpy=0x1b3f410) at ../../src/xcb_lock.c:77 #4 0x7f8bd1b534a0 in _XCBLockDisplay (dpy=0x1b3f410) at ../../src/xcb_lock.c:23 #5 0x7f8bd1b5511f in _XReply (dpy=0x1b3f410, rep=0x7fffdaa913f0, extra=0, discard=1) at ../../src/xcb_io.c:367 #6 0x7f8bd1b437f8 in XSync (dpy=0x1b3f410, discard=0) at ../../src/Sync.c:48 #7 0x7f8bd1b438da in _XSyncFunction (dpy=0x62ce) at ../../src/Synchro.c:37 #8 0x7f8bd1b3a967 in XQueryPointer (dpy=0x1b3f410, w=315, root=0x7fffdaa91508, child=0x7fffdaa91500, root_x=0x7fffdaa914fc, root_y=0x7fffdaa914f8, win_x=0x7fffdaa914f4, win_y=0x7fffdaa914f0, mask=0x7fffdaa914ec) at ../../src/QuPntr.c:64 #9 0x0046771d in CXWindowsKeyState::pollActiveModifiers (this=0x1b58780) at ../../../synergy/lib/platform/CXWindowsKeyState.cpp:141 #10 0x00484a3b in CPlatformScreen::pollActiveModifiers (this=0x1b3f200) at ../../../synergy/lib/synergy/CPlatformScreen.cpp:93 #11 0x004880b6 in CScreen::pollActiveModifiers (this=0x1b40ee0) at ../../../synergy/lib/synergy/CScreen.cpp:397 #12 0x00432b01 in CPrimaryClient::getToggleMask (this=0x1b5de60) at ../../../synergy/lib/server/CPrimaryClient.cpp:89 #13 0x00437c3c in CServer::switchScreen (this=0x1b5e940, dst=0x1b5de60, x=3343, y=817, forScreensaver=false) at ../../../synergy/lib/server/CServer.cpp:492 #14 0x00438c7e in CServer::onMouseMoveSecondary (this=0x1b5e940, dx=-18, dy=-1) at ../../../synergy/lib/server/CServer.cpp:1793 #15 0x0043919f in CServer::handleMotionSecondaryEvent (this=0x1b5e940, [EMAIL PROTECTED]) at ../../../synergy/lib/server/CServer.cpp:1277 #16 0x0043f3e0 in TMethodEventJobCServer::run (this=0x1b5f520, [EMAIL PROTECTED]) at ../../../synergy/lib/base/TMethodEventJob.h:66 #17 0x0049a616 in CEventQueue::dispatchEvent (this=0x7fffdaa918d0, [EMAIL PROTECTED]) at ../../../synergy/lib/base/CEventQueue.cpp:190 #18 0x0040b079 in mainLoop () at ../../../synergy/cmd/synergys/synergys.cpp:685 #19 0x0040b30b in standardStartup (argc=4, argv=0x7fffdaa91ec8) at ../../../synergy/cmd/synergys/synergys.cpp:735 #20 0x00409b14 in run (argc=4, argv=0x7fffdaa91ec8, outputter=0x0, startup=0x40b289 standardStartup) at ../../../synergy/cmd/synergys/synergys.cpp:762 #21 0x00409c6b in main (argc=4, argv=0x7fffdaa91ec8) at ../../../synergy/cmd/synergys/synergys.cpp:1290 And the other thread: (gdb) thread 3 [Switching to thread 3 (Thread 0x42f26950 (LWP 25298))]#0 0x7f8bd1139d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x7f8bd1139d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x7f8bd07c681b in ?? () from /usr/lib/libxcb.so.1 #2 0x7f8bd07c755d in xcb_send_request () from /usr/lib/libxcb.so.1 #3 0x7f8bd1b53e6f in issue_complete_request (dpy=0x1b3f410, veclen=3, vec=0x42f24a60) at ../../src/xcb_lock.c:148 #4 0x7f8bd1b53a93 in _XPutXCBBuffer (dpy=0x1b3f410) at ../../src/xcb_lock.c:203 #5 0x7f8bd1b534cd in _XCBUnlockDisplay (dpy=0x1b3f410) at ../../src/xcb_lock.c:31 #6 0x7f8bd1b3fd25 in XSendEvent (dpy=0x1b3f410, w=18874372, propagate=0, event_mask=0, event=0x1b9bba0) at ../../src/SendEvent.c:81 #7 0x00464633 in CXWindowsEventQueueBuffer::flush (this=0x1b5dc70) at ../../../synergy/lib/platform/CXWindowsEventQueueBuffer.cpp:247 #8 0x004647c6 in CXWindowsEventQueueBuffer::addEvent (this=0x1b5dc70, dataID=2) at ../../../synergy/lib/platform/CXWindowsEventQueueBuffer.cpp:210 #9 0x0049a531 in CEventQueue::addEvent (this=0x7fffdaa918d0, [EMAIL PROTECTED]) at ../../../synergy/lib/base/CEventQueue.cpp:221 #10 0x00492cb2 in CTCPSocket::sendEvent (this=0x1b9a070, type=39) at ../../../synergy/lib/net/CTCPSocket.cpp:358 #11 0x004930c7 in CTCPSocket::serviceConnected (this=0x1b9a070, job=0x7f8bc800a4b0, read=false, write=true, error=false) at ../../../synergy/lib/net/CTCPSocket.cpp:465 #12 0x0049549d in TSocketMultiplexerMethodJobCTCPSocket::run (this=0x7f8bc800a4b0, read=false, write=true, error=false) at ../../../synergy/lib/net/TSocketMultiplexerMethodJob.h:79 #13 0x0048d1e1 in CSocketMultiplexer::serviceThread (this=0x7fffdaa91a10) at ../../../synergy/lib/net/CSocketMultiplexer.cpp:228 #14 0x0048ef2d in
Bug#495498: xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy-request)) = 0)' failed.
The attached patch fixed the problem for me.
This is a hack though, I'm not saying it's the final fix.
It's definitely a good work around for on debian though,
and maybe you will decide that it's the right thing to do,
even.
I got the idea reading Xlib's documentation when I saw
this page:
http://tronche.com/gui/x/xlib/display/XInitThreads.html
--
Carlo Wood [EMAIL PROTECTED]
diff -X /usr/src/debian/synergy/.diffignore -rudp synergy-1.3.1/cmd/synergys/synergys.cpp synergy-1.3.1.XInitThreads/cmd/synergys/synergys.cpp
--- synergy-1.3.1/cmd/synergys/synergys.cpp 2006-03-22 06:40:27.0 +0100
+++ synergy-1.3.1.XInitThreads/cmd/synergys/synergys.cpp 2008-08-19 23:10:03.0 +0200
@@ -1283,6 +1283,10 @@ main(int argc, char** argv)
{
CArgs args;
try {
+if (XInitThreads() == 0)
+{
+ throw XArch(XInitThreads() returned zero);
+}
int result;
CArch arch;
CLOG;
Bug#495498: xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy-request)) = 0)' failed.
Carlo Wood wrote: Please ask if you need more info. Those are helpful, but please be sure to CC the bug, so there's a record that anyone can see and comment on. I've asked the others, but it's worth asking you: do you have the ability to test synergys from 1.3.1-4 on etch? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495498: xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy-request)) = 0)' failed.
On Mon, Aug 18, 2008 at 03:02:01PM -0400, Jeff Licquia wrote: I've asked the others, but it's worth asking you: do you have the ability to test synergys from 1.3.1-4 on etch? Note that I already am running/testing synergy 1.3.1-4. But no, I only have debian lenny/sid on both machines. I could run synergys in an etch chroot though, 64bit or 32bit. The only difference would be the versions of the libraries it links with. -- Carlo Wood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495498: xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy-request)) = 0)' failed.
Carlo Wood wrote: Note that I already am running/testing synergy 1.3.1-4. But no, I only have debian lenny/sid on both machines. I could run synergys in an etch chroot though, 64bit or 32bit. The only difference would be the versions of the libraries it links with. That's exactly what I'm wanting to test. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495498: xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy-request)) = 0)' failed.
On Mon, Aug 18, 2008 at 03:28:41PM -0400, Jeff Licquia wrote: That's exactly what I'm wanting to test. Ok, I installed etch 686 and compiled synergy-1.3.1-4. Running it works a while (as usually) and then also aborts at the moment I leave the client, entering the server. This time however I don't get an assertion but this: [...] DEBUG1: ../../../synergy-1.3.1/lib/platform/CXWindowsClipboard.cpp,1463: got data, 4 bytes DEBUG1: ../../../synergy-1.3.1/lib/platform/CXWindowsClipboard.cpp,1343: request succeeded DEBUG1: ../../../synergy-1.3.1/lib/platform/CXWindowsClipboard.cpp,589: got ICCCM time 325230886 DEBUG: ../../../synergy-1.3.1/lib/platform/CXWindowsClipboard.cpp,348: close clipboard 1 DEBUG: ../../../synergy-1.3.1/lib/server/CServer.cpp,1435: ignored screen hikaru update of clipboard 1 (unchanged) DEBUG1: ../../../synergy-1.3.1/lib/server/CClientProxy1_0.cpp,253: send enter to taryn, 0,702 7 DEBUG1: ../../../synergy-1.3.1/lib/server/CServer.cpp,780: try to leave taryn on left INFO: ../../../synergy-1.3.1/lib/server/CServer.cpp,447: switch from taryn to hikaru at 3353,712 DEBUG1: ../../../synergy-1.3.1/lib/server/CClientProxy1_0.cpp,261: send leave to taryn Xlib: unexpected async reply (sequence 0x14a8)! at that moment I have no mouse or keyboard anymore (as is the case when I run synergys in gdb and it stops in Xlib due to the assertion). So, I had to kill it by logging in remotely from another PC. -- Carlo Wood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495498: xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy-request)) = 0)' failed.
Package: synergy Version: 1.3.1-4 Severity: important Since my last apt-get update/upgrade, synergys crashes more often than before. It now crashes with the output: ... DEBUG1: CClientProxy1_0.cpp,253: send enter to taryn, 0,881 3 DEBUG1: CServer.cpp,780: try to leave taryn on left INFO: CServer.cpp,447: switch from taryn to hikaru at 3345,876 DEBUG1: CClientProxy1_0.cpp,261: send leave to taryn synergys: ../../src/xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy-request)) = 0)' failed. Aborted -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages synergy depends on: ii libc6 2.7-13 GNU C Library: Shared libraries ii libgcc1 1:4.3.1-2 GCC support library ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library ii libsm62:1.0.3-2 X11 Session Management library ii libstdc++64.3.1-2The GNU Standard C++ Library v3 ii libx11-6 2:1.1.4-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxinerama1 2:1.0.3-2 X11 Xinerama extension library ii libxtst6 2:1.0.3-1 X11 Testing -- Resource extension synergy recommends no packages. synergy suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495498: xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy-request)) = 0)' failed.
Carlo Wood wrote: Since my last apt-get update/upgrade, synergys crashes more often than before. It now crashes with the output: ... DEBUG1: CClientProxy1_0.cpp,253: send enter to taryn, 0,881 3 DEBUG1: CServer.cpp,780: try to leave taryn on left INFO: CServer.cpp,447: switch from taryn to hikaru at 3345,876 DEBUG1: CClientProxy1_0.cpp,261: send leave to taryn synergys: ../../src/xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy-request)) = 0)' failed. Aborted I've gotten a number of bug reports on this, and am still trying to figure it out. I take it hikaru is the server, and taryn is the client, set up on the left? Which operating system is taryn running? For both, what is the desktop setup? (The last question may be obvious if the client is Mac OS X or Windows.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
