search

epakai / synergy-debian

Synergy packaging for Debian
Other
4 stars 2 forks source link

[495498] xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy->request)) >= 0)' failed. #41

Closed epakai closed 7 years ago

epakai commented 7 years ago

BTS_msg_id: 20080818015426.2308.38465.reportbug@hikaru.localdomain BTS author: Carlo Wood carlo@alinoe.com

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 0000 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 libsm6 2:1.0.3-2 X11 Session Management library ii libstdc++6 4.3.1-2 The 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

epakai commented 7 years ago

BTS_msg_id: 48A8FAC5.5010503@licquia.org BTS author: Jeff Licquia jeff@licquia.org

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 0000 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.)

epakai commented 7 years ago

BTS_msg_id: 48A9C729.8010708@licquia.org BTS author: Jeff Licquia jeff@licquia.org

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?

epakai commented 7 years ago

BTS_msg_id: 48A9C817.3090801@licquia.org BTS author: Jeff Licquia jeff@licquia.org

epakai commented 7 years ago

BTS_msg_id: 48A9C82A.7080608@licquia.org BTS author: Jeff Licquia jeff@licquia.org

epakai commented 7 years ago

BTS_msg_id: 48A9C837.6010801@licquia.org BTS author: Jeff Licquia jeff@licquia.org

epakai commented 7 years ago

BTS_msg_id: 20080818192733.GA28465@alinoe.com BTS author: Carlo Wood carlo@alinoe.com

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 carlo@alinoe.com

epakai commented 7 years ago

BTS_msg_id: 48A9CD69.3000904@licquia.org BTS author: Jeff Licquia jeff@licquia.org

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.

epakai commented 7 years ago

BTS_msg_id: 20080818203435.GA17041@alinoe.com BTS author: Carlo Wood carlo@alinoe.com

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 0000 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 carlo@alinoe.com

epakai commented 7 years ago

BTS_msg_id: 20080819150400.GA19539@alinoe.com BTS author: Carlo Wood carlo@alinoe.com

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 carlo@alinoe.com

epakai commented 7 years ago

BTS_msg_id: 48AAF580.2010302@licquia.org BTS author: Jeff Licquia jeff@licquia.org

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.

epakai commented 7 years ago

BTS_msg_id: 20080819165609.GA25016@alinoe.com BTS author: Carlo Wood carlo@alinoe.com

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, event=@0x41ebad40) 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::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::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, event=@0x7fff09a7aa80)

at ../../../synergy/lib/server/CServer.cpp:1277

16 0x000000000043f3e0 in TMethodEventJob::run (this=0x2730440, event=@0x7fff09a7aa80)

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, event=@0x416bb010) 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 carlo@alinoe.com

epakai commented 7 years ago

BTS_msg_id: 20080819170136.GA25813@alinoe.com BTS author: Carlo Wood carlo@alinoe.com

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)] 0x00007f8bd0e0def5 in raise () from /lib/libc.so.6 (gdb) bt

0 0x00007f8bd0e0def5 in raise () from /lib/libc.so.6

1 0x00007f8bd0e0f413 in abort () from /lib/libc.so.6

2 0x00007f8bd0e06dc9 in __assert_fail () from /lib/libc.so.6

3 0x00007f8bd1b53740 in _XGetXCBBuffer (dpy=0x1b3f410) at ../../src/xcb_lock.c:77

4 0x00007f8bd1b534a0 in _XCBLockDisplay (dpy=0x1b3f410) at ../../src/xcb_lock.c:23

5 0x00007f8bd1b5511f in _XReply (dpy=0x1b3f410, rep=0x7fffdaa913f0, extra=0, discard=1) at ../../src/xcb_io.c:367

6 0x00007f8bd1b437f8 in XSync (dpy=0x1b3f410, discard=0) at ../../src/Sync.c:48

7 0x00007f8bd1b438da in _XSyncFunction (dpy=0x62ce) at ../../src/Synchro.c:37

8 0x00007f8bd1b3a967 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 0x000000000046771d in CXWindowsKeyState::pollActiveModifiers (this=0x1b58780)

at ../../../synergy/lib/platform/CXWindowsKeyState.cpp:141

10 0x0000000000484a3b in CPlatformScreen::pollActiveModifiers (this=0x1b3f200) at ../../../synergy/lib/synergy/CPlatformScreen.cpp:93

11 0x00000000004880b6 in CScreen::pollActiveModifiers (this=0x1b40ee0) at ../../../synergy/lib/synergy/CScreen.cpp:397

12 0x0000000000432b01 in CPrimaryClient::getToggleMask (this=0x1b5de60) at ../../../synergy/lib/server/CPrimaryClient.cpp:89

13 0x0000000000437c3c in CServer::switchScreen (this=0x1b5e940, dst=0x1b5de60, x=3343, y=817, forScreensaver=false)

at ../../../synergy/lib/server/CServer.cpp:492

14 0x0000000000438c7e in CServer::onMouseMoveSecondary (this=0x1b5e940, dx=-18, dy=-1) at ../../../synergy/lib/server/CServer.cpp:1793

15 0x000000000043919f in CServer::handleMotionSecondaryEvent (this=0x1b5e940, event=@0x7fffdaa91aa0)

at ../../../synergy/lib/server/CServer.cpp:1277

16 0x000000000043f3e0 in TMethodEventJob::run (this=0x1b5f520, event=@0x7fffdaa91aa0)

at ../../../synergy/lib/base/TMethodEventJob.h:66

17 0x000000000049a616 in CEventQueue::dispatchEvent (this=0x7fffdaa918d0, event=@0x7fffdaa91aa0)

at ../../../synergy/lib/base/CEventQueue.cpp:190

18 0x000000000040b079 in mainLoop () at ../../../synergy/cmd/synergys/synergys.cpp:685

19 0x000000000040b30b in standardStartup (argc=4, argv=0x7fffdaa91ec8) at ../../../synergy/cmd/synergys/synergys.cpp:735

20 0x0000000000409b14 in run (argc=4, argv=0x7fffdaa91ec8, outputter=0x0, startup=0x40b289 )

at ../../../synergy/cmd/synergys/synergys.cpp:762

21 0x0000000000409c6b 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 0x00007f8bd1139d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt

0 0x00007f8bd1139d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0

1 0x00007f8bd07c681b in ?? () from /usr/lib/libxcb.so.1

2 0x00007f8bd07c755d in xcb_send_request () from /usr/lib/libxcb.so.1

3 0x00007f8bd1b53e6f in issue_complete_request (dpy=0x1b3f410, veclen=3, vec=0x42f24a60) at ../../src/xcb_lock.c:148

4 0x00007f8bd1b53a93 in _XPutXCBBuffer (dpy=0x1b3f410) at ../../src/xcb_lock.c:203

5 0x00007f8bd1b534cd in _XCBUnlockDisplay (dpy=0x1b3f410) at ../../src/xcb_lock.c:31

6 0x00007f8bd1b3fd25 in XSendEvent (dpy=0x1b3f410, w=18874372, propagate=0, event_mask=0, event=0x1b9bba0) at ../../src/SendEvent.c:81

7 0x0000000000464633 in CXWindowsEventQueueBuffer::flush (this=0x1b5dc70)

at ../../../synergy/lib/platform/CXWindowsEventQueueBuffer.cpp:247

8 0x00000000004647c6 in CXWindowsEventQueueBuffer::addEvent (this=0x1b5dc70, dataID=2)

at ../../../synergy/lib/platform/CXWindowsEventQueueBuffer.cpp:210

9 0x000000000049a531 in CEventQueue::addEvent (this=0x7fffdaa918d0, event=@0x42f24d40) at ../../../synergy/lib/base/CEventQueue.cpp:221

10 0x0000000000492cb2 in CTCPSocket::sendEvent (this=0x1b9a070, type=39) at ../../../synergy/lib/net/CTCPSocket.cpp:358

11 0x00000000004930c7 in CTCPSocket::serviceConnected (this=0x1b9a070, job=0x7f8bc800a4b0, read=false, write=true, error=false)

at ../../../synergy/lib/net/CTCPSocket.cpp:465

12 0x000000000049549d in TSocketMultiplexerMethodJob::run (this=0x7f8bc800a4b0, read=false, write=true, error=false)

at ../../../synergy/lib/net/TSocketMultiplexerMethodJob.h:79

13 0x000000000048d1e1 in CSocketMultiplexer::serviceThread (this=0x7fffdaa91a10) at ../../../synergy/lib/net/CSocketMultiplexer.cpp:228

14 0x000000000048ef2d in TMethodJob::run (this=0x1b40f70) at ../../../synergy/lib/base/TMethodJob.h:63

15 0x0000000000498b57 in CThread::threadFunc (vjob=0x1b40f70) at ../../../synergy/lib/mt/CThread.cpp:152

16 0x00000000004b0cc8 in CArchMultithreadPosix::doThreadFunc (this=0x1b3b010, thread=0x1b3eca0)

at ../../../synergy/lib/arch/CArchMultithreadPosix.cpp:720

17 0x00000000004b0e32 in CArchMultithreadPosix::threadFunc (vrep=0x1b3eca0) at ../../../synergy/lib/arch/CArchMultithreadPosix.cpp:701

18 0x00007f8bd1135fc7 in start_thread () from /lib/libpthread.so.0

19 0x00007f8bd0eab7cd in clone () from /lib/libc.so.6

20 0x0000000000000000 in ?? ()

I'm pretty sure this is the problem: You are calling XSendEvent (or XSync or whatever) from one thread and at the same time XQueryPointer (or whatever) from another thread. That is not allowed. You should do all calls from one thread.

-- Carlo Wood carlo@alinoe.com

epakai commented 7 years ago

BTS_msg_id: 20080819211815.GA6185@alinoe.com BTS author: Carlo Wood carlo@alinoe.com

--qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline

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 carlo@alinoe.com

--qDbXVdCdHGoSgWSk Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="XInitThreads.diff"

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.000000000 +0100 +++ synergy-1.3.1.XInitThreads/cmd/synergys/synergys.cpp 2008-08-19 23:10:03.000000000 +0200 @@ -1283,6 +1283,10 @@ main(int argc, char** argv) { CArgs args; try {

--qDbXVdCdHGoSgWSk--

epakai commented 7 years ago

BTS_msg_id: 48C5D2AA.6070902@debian.org BTS author: Jeff Licquia licquia@debian.org

forcemerge 495498 493706 494368 thanks

epakai commented 7 years ago

BTS_msg_id: E1KcsYN-0008Om-4i@ries.debian.org BTS author: Jeff Licquia licquia@debian.org

Source: synergy Source-Version: 1.3.1-5

We believe that the bug you reported is fixed in the latest version of synergy, which is due to be installed in the Debian FTP archive:

synergy_1.3.1-5.diff.gz to pool/main/s/synergy/synergy_1.3.1-5.diff.gz synergy_1.3.1-5.dsc to pool/main/s/synergy/synergy_1.3.1-5.dsc synergy_1.3.1-5_i386.deb to pool/main/s/synergy/synergy_1.3.1-5_i386.deb

A summary of the changes between this version and the previous one is attached.

Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 495498@bugs.debian.org, and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software pp. Jeff Licquia licquia@debian.org (supplier of updated synergy package)

(This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@debian.org)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Format: 1.8 Date: Sun, 07 Sep 2008 23:25:43 -0400 Source: synergy Binary: synergy Architecture: source i386 Version: 1.3.1-5 Distribution: unstable Urgency: low Maintainer: licquia@debian.org Changed-By: Jeff Licquia licquia@debian.org Description: synergy - Share mouse, keyboard and clipboard over the network Closes: 495498 Changes: synergy (1.3.1-5) unstable; urgency=low .

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkjF1eQACgkQYApVP/ZmyR2e0wCeID2+9qCFBzzGW8Ccb+SbBn8k +gAAoIob5jTFwOeQG9H+Ea72O7e4qAw7 =qjqK -----END PGP SIGNATURE-----

epakai commented 7 years ago

BTS_msg_id: Bug archived. BTS author: $requester

A New Hope

A log time ago, in a galaxy far, far away

something happened.

#

Magically this resulted in the following

action being taken, but this fake control

message doesn't tell you why it happened

#

The action:

Bug archived.

thanks

This fakemail brought to you by your local debbugs

administrator