External developers confirm there is a bug in synergy when running in 64-bit mode. The patch can be found here:
Still, this problem was found while investigation for another NPE thrown from XClipboard.getContents(), so we should also check if the patch help with the original NPE from XNETProtocol.getState() or not.
Some more technical details from Java's point of view. When user requests clipboard contents, AWT first requests a value of TARGETS atom for CLIPBOARD selection (I suspect the owner is some synergy server window). The code is in XSelection.getFormats():
XlibWrapper.XConvertSelection(XToolkit.getDisplay(), // X display connection
getSelectionAtom().getAtom(), // CLIPBOARD atom
XDataTransferer.TARGETS_ATOM.getAtom(), // TARGETS atom
selectionPropertyAtom.getAtom(), // "XAWT-SELECTION" to fill
XWindow.getXAWTRootWindow().getWindow(), // requestor window
The call is successful, and the next thing is to get the value of "XAWT-SELECTION" and convert it to the list of atoms. Here is the list on my linux with synergy client running: 0x189, 0x18a, 0x18b, 0x194, 0xf4, 0x195, 0x196, 0x197, 0x1f, 0x0, 0x14aa1, 0xfffffffff9530698, 0xfffffffff9530698, 0x18a, 0x18b, 0x194, 0xf4, 0x195
Value 0x0 seems odd to me, as well as other repeating values. This only happens when Java and one of synergy clients are started from 64-bit linux, regardless of where synergy server is running.