synergyc crashed with SIGSEGV in std::_Rb_tree_increment()

StacktraceTop:CXWindowsClipboard::pushReplies (this=0x80c8990) at /usr/include/c++/4.1.3/bits/stl_tree.h:182
CXWindowsClipboard::addRequest (this=0x80c8990, owner=56623108, requestor=14680237, target=328,
CXWindowsScreen::handleSystemEvent (this=0x80b5db8, event=@0xbfdd5a8c) at CXWindowsScreen.cpp:1217
TMethodEventJob<CXWindowsScreen>::run (this=0x80c8e28, event=@0xbfdd5a8c)
CEventQueue::dispatchEvent (this=0xbfdd59a8, event=@0xbfdd5a8c) at CEventQueue.cpp:190

Same here, was working fine, then at the moment I tried to swap screens, synergys died.

when to fix this bug?
won't update to Hardy only because this bug, now.
without synergyc, work with two computers is very discommodious

effenberg@effenberg-mobile:~$ uname -a
Linux effenberg-mobile 2.6.24-12-generic #1 SMP Wed Mar 12 23:01:54 UTC 2008 i686 GNU/Linux
effenberg@effenberg-mobile:~$ synergys --version
synergys 1.3.1, protocol version 1.3
Copyright (C) 2002 Chris Schoeneman
effenberg@effenberg-mobile:~$ dmesg | grep synergys
[19368.223163] synergys[9373]: segfault at 08206344 eip b7d5e0d2 esp bfcbe804 error 4
effenberg@effenberg-mobile:~$

I use Synergy Server in my Ubuntu desktop and Synergy Client in a Windows XP Laptop. This setup is used for more than a year without a single crash. It started happening when I upgraded to Hardy. I can't detect what makes it crash: I use it for hours without any problems and it suddenly crashes. Sometimes the PCs are not even being used when this crash occurs.

Regards,
Effenberg

I'm wondering if newer versions of synergy don't sanitize the data it transmits and recieves very well. I'd venture to guess it's either expecting data that no longer exists or popping bad data into use. This is pretty common with any server/client that isn't very strict with how data is transmitted and received. For instance I sometimes notice improved reliability when using encapsulated tcp proxies for programs that expect interactive traffic like synergy does.

I get similar behaviour.
Seems to happen most often when copying to clipboard in windows client, but not predictably by any means.
Fortunately doesn't happen more than once or twice a day, so I just run synergys in a respawn loop.

Just to let you know -- this hasn't happened to me since around the
time I submitted this bug report. No hardware changes, no (related)
software changes except normal upgrade process.

An interesting (but probably unrelated) thing I have noticed is that
sometimes the clipboard copy just fails. I can copy something (from a
simple url through to a multi-1600x1200-screenshot) and nothing is in
the clipboard on the other end, even if I try multiple times. When I
try 5 minutes later, all is well. Although, monitoring the data, I
can see that something around the right size is being passed across.

More of an minor annoyance than anything else, but it's an indication
that some of the data isn't necessarily always making it where it
should.

Paul.

On Sat, Sep 27, 2008 at 7:42 AM, Derek <email address hidden> wrote:
> I get similar behaviour.
> Seems to happen most often when copying to clipboard in windows client, but not predictably by any means.
> Fortunately doesn't happen more than once or twice a day, so I just run synergys in a respawn loop.
>
> --
> synergyc crashed with SIGSEGV in std::_Rb_tree_increment()
> https://bugs.launchpad.net/bugs/148968
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I've written the following nasty script to allow me to automatically restart synergyc when it crashes, which it does 5-6 times per hour on my current setup.

It'd be nice to get this fixed, but in the mean time, others may find this helpful. It basically watches for the synergyc process to vanish and spawns another one, checking every 2s.

Whups. The original script had a major bug that meant it thought the script itself was the client! Try this version instead.

Just had this same error pop up. I've been using synergy for over a year now and I haven't installed any updates today so I'm not sure what caused it. I'm running an XP server on my desktop and Ubuntu 8.10 on my laptop. I attached the .crash file in case anyone can find anything useful in it.
Out of curiosity, is synergy actually being maintained anymore? I haven't seen a new version since 2006.

Just noticed Paul Hannah's comment above - I experience the same behaviour. It seems random and I can't figure out why the clipboard works sometimes but not others. I also have no idea how to debug it but I'd be happy to try if someone explained how.

Unfortunately this is not easily reproducible, it happens and nags me only when I'm doing something else but not when I'm trying to reproduce it...
I think I have a work-around, if you launch synergy server from a VT(the screen that shows when pressing Ctrl+Alt+F1/F2/F3/etc...) instead of a terminal emulator inside X, the bug doesn't happen... try it and tell me.

This could be similar to a bug found (and fixed) on Fedora Core. The updated code has dependencies of a newer code on libstdc++, but this libstdc++ version is not provided on Ubuntu 8.10. See https://bugzilla.redhat.com/show_bug.cgi?id=434539

I can confirm that this is usually related to copy/paste actions. I've seen suggestions elsewhere that shutting down clipboard managers like the KDE Klipper would help (the Gnome clipboard manager has also been mentioned). I'm currently running KDE on the client and server, and I've stopped Klipper on both ends. The frequency of crashes has indeed been reduced, but I just had another unprovoked crash with the same log message. Still, it might help as a temporary partial workaround if this is driving you nuts.

It happens in Lucid too

the synergys (server) not the client that crash In my case, but has the same behavior, but the frequency is much higher : 1crash/2hours

SIGSEGV, Segmentation fault.
0xb7de0eb1 in std::_Rb_tree_increment(std::_Rb_tree_node_base*) () from /usr/lib/libstdc++.so.6
i use maverick and the 1.3.1-6ubuntu1 version of synergy

That version has died long ago; no more supported