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