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 0x00007f8000120d29
in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
(gdb) bt
#0 0x00007f8000120d29 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#1 0x00007f7fff7ad8bb in _xcb_lock_io () from /usr/lib/libxcb.so.1
#2 0x00007f7fff9c0a09 in xcb_xlib_lock () from /usr/lib/libxcb-xlib.so.0
#3 0x00007f8000b3b59a in condition_wait (dpy=0x27103a0, cv=0x2770fb8) at
../../src/xcb_io.c:76
#4 0x00007f8000b3b8c4 in process_responses (dpy=0x27103a0,
wait_for_first_event=0, current_error=0x41ebaa60, current_request=7465) at
../../src/xcb_io.c:151
#5 0x00007f8000b3c141 in _XReply (dpy=0x27103a0, rep=0x41ebaab0, extra=0,
discard=1) at ../../src/xcb_io.c:370
#6 0x00007f8000b2a7f8 in XSync (dpy=0x27103a0, discard=0) at
../../src/Sync.c:48
#7 0x00007f8000b2a8da in _XSyncFunction (dpy=0x2712234) at
../../src/Synchro.c:37
#8 0x00007f8000b26d46 in XSendEvent (dpy=0x27103a0, w=18874372, propagate=0,
event_mask=0, event=0x2760320) at ../../src/SendEvent.c:82
#9 0x0000000000464633 in CXWindowsEventQueueBuffer::flush (this=0x272ec10) at
../../../synergy/lib/platform/CXWindowsEventQueueBuffer.cpp:247
#10 0x00000000004647c6 in CXWindowsEventQueueBuffer::addEvent (this=0x272ec10,
dataID=5) at ../../../synergy/lib/platform/CXWindowsEventQueueBuffer.cpp:210
#11 0x000000000049a531 in CEventQueue::addEvent (this=0x7fff09a7a8b0, [EMAIL
PROTECTED]) at ../../../synergy/lib/base/CEventQueue.cpp:221
#12 0x0000000000492cb2 in CTCPSocket::sendEvent (this=0x276aea0, type=38) at
../../../synergy/lib/net/CTCPSocket.cpp:358
#13 0x00000000004930c7 in CTCPSocket::serviceConnected (this=0x276aea0,
job=0x276cff0, read=false, write=true, error=false) at
../../../synergy/lib/net/CTCPSocket.cpp:465
#14 0x000000000049549d in TSocketMultiplexerMethodJob<CTCPSocket>::run
(this=0x276cff0, read=false, write=true, error=false) at
../../../synergy/lib/net/TSocketMultiplexerMethodJob.h:79
#15 0x000000000048d1e1 in CSocketMultiplexer::serviceThread
(this=0x7fff09a7a9f0) at ../../../synergy/lib/net/CSocketMultiplexer.cpp:228
#16 0x000000000048ef2d in TMethodJob<CSocketMultiplexer>::run (this=0x2711f70)
at ../../../synergy/lib/base/TMethodJob.h:63
#17 0x0000000000498b57 in CThread::threadFunc (vjob=0x2711f70) at
../../../synergy/lib/mt/CThread.cpp:152
...
while thread 1 is:
(gdb) bt
#0 0x00007f8000123394 in __lll_lock_wait () from /lib/libpthread.so.0
#1 0x00007f8000121270 in pthread_cond_broadcast@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#2 0x00007f7fff9c0ac2 in xcb_xlib_unlock () from /usr/lib/libxcb-xlib.so.0
#3 0x00007f8000b3b550 in condition_wait (dpy=0x27103a0, cv=0x2770fb8) at
../../src/xcb_io.c:74
#4 0x00007f8000b3b8c4 in process_responses (dpy=0x27103a0,
wait_for_first_event=0, current_error=0x7fff09a7a380, current_request=7466)
at ../../src/xcb_io.c:151
#5 0x00007f8000b3c141 in _XReply (dpy=0x27103a0, rep=0x7fff09a7a3d0, extra=0,
discard=1) at ../../src/xcb_io.c:370
#6 0x00007f8000b2a7f8 in XSync (dpy=0x27103a0, discard=0) at
../../src/Sync.c:48
#7 0x00007f8000b2a8da in _XSyncFunction (dpy=0x2712230) at
../../src/Synchro.c:37
#8 0x00007f8000b21967 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 0x000000000046771d in CXWindowsKeyState::pollActiveModifiers
(this=0x2729720)
at ../../../synergy/lib/platform/CXWindowsKeyState.cpp:141
#10 0x0000000000484a3b in CPlatformScreen::pollActiveModifiers (this=0x2710190)
at ../../../synergy/lib/synergy/CPlatformScreen.cpp:93
#11 0x00000000004880b6 in CScreen::pollActiveModifiers (this=0x2711ee0) at
../../../synergy/lib/synergy/CScreen.cpp:397
#12 0x0000000000432b01 in CPrimaryClient::getToggleMask (this=0x272ee00) at
../../../synergy/lib/server/CPrimaryClient.cpp:89
#13 0x0000000000437c3c in CServer::switchScreen (this=0x272f860, dst=0x272ee00,
x=3355, y=672, forScreensaver=false)
at ../../../synergy/lib/server/CServer.cpp:492
#14 0x0000000000438c7e in CServer::onMouseMoveSecondary (this=0x272f860,
dx=-10, dy=0) at ../../../synergy/lib/server/CServer.cpp:1793
#15 0x000000000043919f in CServer::handleMotionSecondaryEvent (this=0x272f860,
[EMAIL PROTECTED])
at ../../../synergy/lib/server/CServer.cpp:1277
#16 0x000000000043f3e0 in TMethodEventJob<CServer>::run (this=0x2730440, [EMAIL
PROTECTED])
at ../../../synergy/lib/base/TMethodEventJob.h:66
...
thread 2 was handling my attempt to stop gdb with ^C, which was caught by
synergys it seems. Because this uses CEventQueue::addEvent, as was already
called by thread 3, it dead locked too:
(gdb) thread 2
[Switching to thread 2 (Thread 0x416bb950 (LWP 24058))]#0 0x00007f8000123394
in __lll_lock_wait () from /lib/libpthread.so.0
(gdb) bt
#0 0x00007f8000123394 in __lll_lock_wait () from /lib/libpthread.so.0
#1 0x00007f800011ebf0 in _L_lock_102 () from /lib/libpthread.so.0
#2 0x00007f800011e4fe in pthread_mutex_lock () from /lib/libpthread.so.0
#3 0x00000000004b17ad in CArchMultithreadPosix::lockMutex (this=0x270c010,
mutex=0x2711e50) at ../../../synergy/lib/arch/CArchMultithreadPosix.cpp:293
#4 0x00000000004ac97e in CArch::lockMutex (this=0x7fff09a7ac70,
mutex=0x2711e50) at ../../../synergy/lib/arch/CArch.cpp:320
#5 0x00000000004a35e8 in CArchMutexLock (this=0x416bafa0, mutex=0x2711e50) at
../../../synergy/lib/arch/CArch.h:207
#6 0x000000000049a502 in CEventQueue::addEvent (this=0x7fff09a7a8b0, [EMAIL
PROTECTED]) at ../../../synergy/lib/base/CEventQueue.cpp:215
#7 0x000000000049baef in interrupt () at
../../../synergy/lib/base/CEventQueue.cpp:27
#8 0x00000000004b1622 in CArchMultithreadPosix::raiseSignal (this=0x270c010,
signal=kINTERRUPT) at ../../../synergy/lib/arch/CArchMultithreadPosix.cpp:571
#9 0x00000000004accf4 in CArch::raiseSignal (this=0x7fff09a7ac70,
signal=IArchMultithread::kINTERRUPT) at ../../../synergy/lib/arch/CArch.cpp:410
#10 0x00000000004b1dcc in CArchMultithreadPosix::threadSignalHandler () at
../../../synergy/lib/arch/CArchMultithreadPosix.cpp:784
#11 0x00007f800011cfc7 in start_thread () from /lib/libpthread.so.0
#12 0x00007f7fffe927cd in clone () from /lib/libc.so.6
#13 0x0000000000000000 in ?? ()
this thread seems not relevant (although I think it's bad to wait
for a lock when handling SIGINT).
The problem is the deadlock between thread 1 and thread 3.
--
Carlo Wood <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
