(josm is the java openstreetmap editor)
Steps to reproduce: 1) xpra start :4 2) DISPLAY=:4 gnome-terminal & 3) xpra attach :4 & 4) josm 5) in gnome-terminal: select some text in and choose Edit->Copy 6) in josm: choose Files->Download from OSM
Expected results: 6) josm shows a dialog that lets you choose the location.
Actual results: 6) josm shows a dialog with "Unexpected Exception" and prints the following to stderr:
Atom was 0 java.lang.NullPointerException: Failed to retrieve atom name. at sun.awt.X11.XlibWrapper.XGetAtomName(Native Method) at sun.awt.X11.XAtom.getName(XAtom.java:186) at sun.awt.X11.XDataTransferer.getTargetNameForAtom(XDataTransferer.java:141) at sun.awt.X11.XDataTransferer.getNativeForFormat(XDataTransferer.java:130) at sun.awt.datatransfer.DataTransferer.getFlavorsForFormats(DataTransferer.java:785) at sun.awt.datatransfer.ClipboardTransferable.<init>(ClipboardTransferable.java:89) at sun.awt.X11.XClipboard.getContents(XClipboard.java:101) at org.openstreetmap.josm.gui.tagging.ac.AutoCompletingComboBox$AutoCompletingComboBoxDocument.insertString(AutoCompletingComboBox.java:117) at javax.swing.text.AbstractDocument.replace(AbstractDocument.java:672) at javax.swing.text.JTextComponent.setText(JTextComponent.java:1707) at javax.swing.plaf.metal.MetalComboBoxEditor$1.setText(MetalComboBoxEditor.java:61) at javax.swing.plaf.basic.BasicComboBoxEditor.setItem(BasicComboBoxEditor.java:77) at org.openstreetmap.josm.gui.tagging.ac.AutoCompletingComboBox.configureEditor(AutoCompletingComboBox.java:191) at javax.swing.plaf.basic.BasicComboBoxUI$Handler.contentsChanged(BasicComboBoxUI.java:1821) at javax.swing.AbstractListModel.fireContentsChanged(AbstractListModel.java:117) at javax.swing.DefaultComboBoxModel.setSelectedItem(DefaultComboBoxModel.java:105) at org.openstreetmap.josm.gui.widgets.ComboBoxHistory.addElement(ComboBoxHistory.java:77) at org.openstreetmap.josm.gui.tagging.ac.AutoCompletingComboBox.setPossibleItems(AutoCompletingComboBox.java:228) at org.openstreetmap.josm.gui.download.PlaceSelection.buildSearchPanel(PlaceSelection.java:116) at org.openstreetmap.josm.gui.download.PlaceSelection.addGui(PlaceSelection.java:138) at org.openstreetmap.josm.gui.download.DownloadDialog.buildMainPanel(DownloadDialog.java:117) at org.openstreetmap.josm.gui.download.DownloadDialog.<init>(DownloadDialog.java:193) at org.openstreetmap.josm.gui.download.DownloadDialog.getInstance(DownloadDialog.java:63) at org.openstreetmap.josm.actions.DownloadAction.actionPerformed(DownloadAction.java:35) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2012) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2335) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:404) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) at javax.swing.AbstractButton.doClick(AbstractButton.java:374) at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:829) at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:873) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289) at java.awt.Component.processMouseEvent(Component.java:6268) at javax.swing.JComponent.processMouseEvent(JComponent.java:3267) at java.awt.Component.processEvent(Component.java:6033) at java.awt.Container.processEvent(Container.java:2045) at java.awt.Component.dispatchEventImpl(Component.java:4629) at java.awt.Container.dispatchEventImpl(Container.java:2103) at java.awt.Component.dispatchEvent(Component.java:4455) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4633) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4297) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4227) at java.awt.Container.dispatchEventImpl(Container.java:2089) at java.awt.Window.dispatchEventImpl(Window.java:2517) at java.awt.Component.dispatchEvent(Component.java:4455) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:649) at java.awt.EventQueue.access$000(EventQueue.java:96) at java.awt.EventQueue$1.run(EventQueue.java:608) at java.awt.EventQueue$1.run(EventQueue.java:606) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:105) at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:116) at java.awt.EventQueue$2.run(EventQueue.java:622) at java.awt.EventQueue$2.run(EventQueue.java:620) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:105) at java.awt.EventQueue.dispatchEvent(EventQueue.java:619) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177) at java.awt.EventDispatchThread.run(EventDispatchThread.java:138)
More info: 1) If I click "Do Nothing", open a local (non-xpra) gnome-terminal and select some text from it I can continue using josm normally. 2) I'm using xpra 0.3.2+dfsg-1 from Debian unstable and josm 0.0.svn5267+dfsg1-1. gnome-terminal is 2.30.2-1.
Related tickets and changesets:
Xpra sun.awt.X11.XlibWrapper.XGetAtomName
issue"
Will test.
Hmmm, I'll try again with the 0.3 branch but I cannot reproduce it with trunk so far.
Just to clarify, step (5) "in gnome-terminal" (this gnome terminal is not part of the xpra session, is it? - in any case, I tried both)
Does the error happen as soon as "Files->Download from OSM" is clicked? I've pasted the value I copied into the clipboard in various places without effect.
Also, can you please specify the bitness of both client and server? (64 vs 32) Does this still happen when running on the same box? (or a box with the same bitness)
Step "2) DISPLAY=:4 gnome-terminal &" starts the gnome-terminal so that it will be accessed over xpra yes.
The error happens immediately when you click "Download from OSM", you will not get the expected dialog at all.
This is amd64, client and server are the same machine as you can guess from "3) xpra attach :4 &"
Screencast to show exactly what happens:
http://lindi.iki.fi/lindi/screencast/xpra-bug-162.webm
The only thing I managed to get is this:
/xpra/platform/clipboard_base.py:247: GtkWarning: \ IA__gdk_x11_atom_to_xatom_for_display: \ assertion `ATOM_TO_INDEX (atom) < virtual_atom_array->len' failed \ gtk.Invisible.do_selection_request_event(self, event)
Which I will investigate, as this may be the cause of the problem.
That is using debian testing with the following packages:
ii gnome-terminal 3.4.1.1-1 GNOME terminal emulator application ii josm 0.0.svn5267+df Editor for OpenStreetMap ii xpra 0.3.2+dfsg-1 tool to detach/reattach running X programs
Also tested with xpra from 0.3.x branch... still no Java error.
Apparently this bug also happens when pasting into matlab.
Installed 'sid' in a VM and followed the instructions *exactly*. No errors, just the warning as per comment:5.
(from the bug description I was not 100% certain that josm was started within xpra or not so I tried both just in case)
Will have to close this bug if I can't reproduce it... Hopefully fixing the warning will fix the bug.
Hmm, surely the screencast shows that josm was not started within xpra?
Should I start attaching virtual machine images next? What VMs are you using?
Hah, didn't think of checking the screencast again. Anyway, since I tried both options, this doesn't matter. I did it all again, side by side - at the same speed as the screencast... still no crash.
I am using a debian sid image which I created by cloning my wheezy image and "dist-upgrade"ing it to sid. I really don't know what to do next to reproduce the bug. Feel free to put your VM for download (compressed obviously).
Did you use josm before on this box? Maybe the bug requires existing/specific .josm/
data? Does it happen with a clean new user too?
No it was a fresh installation so no .josm.
Found this bug which seems related: mozilla #495392: it mentions java apps (matlab), gtk atoms, etc
gtk_selection_data_get_data_type(selection_data) == gdk_atom_intern("TARGETS", FALSE) before calling gtk_selection_data_get_targets(), and, if so and gtk_selection_data_get_format(selection_data) == 32, assume XA_ATOM type and use gdk_x11_xatom_to_atom() to do the conversion to GdkAtom
. (But the GTK bug should still be fixed.)"
lindi, can you confirm that the video was recorded on a plain machine, not a virtual machine, or something like that? No clipboard manager installed either?
Also, please provide client and server logs with r1145 and this change to clipboard_base.py
:
debug = log.info #debug = log.debug
Yeah no virtual machines used here. I am not sure if gnome3 counts as a clipboard manager or not.
full package list found on the sid VM
Attached above is the full package list from this sid VM.
(no: gnome3 does not count as a clipboard manager - I was thinking of things like klipper, which are known to cause problems by constantly messing with the clipboard, even when nothing is happening)
I can reproduce the issue if I boot the following livecd:
It's debian wheezy with task-gnome-desktop, xpra and josm packages.
I cannot reproduce using this iso, only a warning. But now that the warning is also fixed, following the significant fixes from r1226 and r1219, I'm not going to spend much more time on this. I will just backport those fixes to 0.3.x and 0.4.x
r1224 and and r1225 also cleanup the code and all the recent changesets also make the debug logging more useful. If the problem still occurs, please apply the one-liner change from comment:11
Although that still does not explain why I couldn't reproduce the bug, r1228 fixes a long standing bug with GdkAtom
and ensures we do send the atom's names and not their values! (bloody variable names!)
It would cause exactly the kinds of bugs reported here.
I upgrade to the last version in SVN and I still have the problem with matlab.
Server log:
2012-07-31 10:26:40,066 do_selection_request_event(<gtk.gdk.Event at 0x7f8e29877f80: GDK_SELECTION_REQUEST selection=PRIMARY, target=TARGETS, property=XAWT_SELECTION>) 2012-07-31 10:26:40,067 do_selection_request_event(<gtk.gdk.Event at 0x7f8e29877f80: GDK_SELECTION_REQUEST selection=PRIMARY, target=TARGETS, property=XAWT_SELECTION>) target=TARGETS, selection=PRIMARY 2012-07-31 10:26:40,067 do_selection_get(<GtkSelectionData at 0x7fffc3d4d740>, 0, 1542692228) 2012-07-31 10:26:40,067 get clipboard from remote handler id=13 2012-07-31 10:26:40,072 process clipboard packet type=clipboard-contents 2012-07-31 10:26:40,072 process clipboard contents, selection=PRIMARY, type=ATOM, format=32 2012-07-31 10:26:40,072 _munge_wire_selection_to_raw(integers, ATOM, 32, <type 'list'>:2) 2012-07-31 10:26:40,072 wire selection to raw, encoding=integers, type=ATOM, format=32, len(data)=2 2012-07-31 10:26:40,072 struct.pack(@LL, [49253, 49302]) 2012-07-31 10:26:40,072 clipboard wire -> raw: ('ATOM', 32, 'integers', [49253, 49302]) -> 'e\xc0\x00\x00\x00\x00\x00\x00\x96\xc0\x00\x00\x00\x00\x00\x00' 2012-07-31 10:26:40,073 got clipboard contents(13)=16 (type=ATOM, format=32) Atom was 0 10:26:40,073 get clipboard from remote result(13)={'data': 'e\xc0\x00\x00\x00\x00\x00\x00\x96\xc0\x00\x00\x00\x00\x00\x00', 'type': 'ATOM', 'format': 32} 2012-07-31 10:26:40,073 do_selection_get(<GtkSelectionData at 0x7fffc3d4d740>,0,1542692228) calling selection_data.set(ATOM, 32, <type 'str'>:16)
I couldn't find the log on the client (windows), the file in my %USERPROFILE%/Application Data/Xpra
is old.
Hah, here's a piece of the puzzle I did not have: you're connecting from a windows pc, right? What I am seeing in the debug log (thanks!) looks exactly like the bug I've just fixed (except the fix is not used in the windows codepath..)
I'll see what I can do on MS Windows. Can you confirm that matlab does not have problems with up-to-date xpra on non-windows clients?
Well i don't have a non windows clients at end ... I guess I could connect a client via a Forward X11 session ... let me see what I can do !
Here's what i did:
here's the log
2012-07-31 10:56:43,889 process clipboard packet type=clipboard-request 2012-07-31 10:56:43,889 process clipboard request, request_id=9, selection=PRIMARY, local name=PRIMARY, target=TARGETS 2012-07-31 10:56:43,889 get_contents(TARGETS,<function got_contents at 0x10e9a28>) 2012-07-31 10:56:43,900 got_contents(ATOM, 32, <type 'str'>:96) data=[123, 0, 0, 0, 0, 0, 0, 0, 119, 0, 0, 0, 0, 0, 0, 0, 122, 0, 0, 0, 0, 0, 0, 0, 125, 0, 0, 0, 0, 0, 0, 0, 126, 0, 0, 0, 0, 0, 0, 0, 71, 0, 0, 0, 0, 0, 0, 0, 127, 0, 0, 0, 0, 0, 0, 0, 128, 0, 0, 0, 0, 0, 0, 0, 31, 0, 0, 0, 0, 0, 0, 0, 129, 0, 0, 0, 0, 0, 0, 0, 130, 0, 0, 0, 0, 0, 0, 0, 131, 0, 0, 0, 0, 0, 0, 0], str(data)={wz}~G���� 2012-07-31 10:56:43,900 _do_munge_raw_selection_to_wire(TARGETS, ATOM, 32, <type 'str'>:96) atoms=[<GdkAtom 0x7b = 'TIMESTAMP'>, <GdkAtom 0x77 = 'TARGETS'>, <GdkAtom 0x7a = 'MULTIPLE'>, <GdkAtom 0x7d = 'GTK_TEXT_BUFFER_CONTENTS'>, <GdkAtom 0x7e = 'application/x-gtk-text-buffer-rich-text'>, <GdkAtom 0x47 = 'UTF8_STRING'>, <GdkAtom 0x7f = 'COMPOUND_TEXT'>, <GdkAtom 0x80 = 'TEXT'>, <GdkAtom 0x1f = 'STRING'>, <GdkAtom 0x81 = 'text/plain;charset=utf-8'>, <GdkAtom 0x82 = 'text/plain;charset=ANSI_X3.4-1968'>, <GdkAtom 0x83 = 'text/plain'>], atom_names=['TIMESTAMP', 'TARGETS', 'MULTIPLE', 'GTK_TEXT_BUFFER_CONTENTS', 'application/x-gtk-text-buffer-rich-text', 'UTF8_STRING', 'COMPOUND_TEXT', 'TEXT', 'STRING', 'text/plain;charset=utf-8', 'text/plain;charset=ANSI_X3.4-1968', 'text/plain'] 2012-07-31 10:56:43,901 clipboard raw -> wire: ('ATOM', 32, '{\x00\x00\x00\x00\x00\x00\x00w\x00\x00\x00\x00\x00\x00\x00z\x00\x00\x00\x00\x00\x00\x00}\x00\x00\x00\x00\x00\x00\x00~\x00\x00\x00\x00\x00\x00\x00G\x00\x00\x00\x00\x00\x00\x00\x7f\x00\x00\x00\x00\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00\x1f\x00\x00\x00\x00\x00\x00\x00\x81\x00\x00\x00\x00\x00\x00\x00\x82\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00') -> ('atoms', ['TIMESTAMP', 'TARGETS', 'MULTIPLE', 'GTK_TEXT_BUFFER_CONTENTS', 'application/x-gtk-text-buffer-rich-text', 'UTF8_STRING', 'COMPOUND_TEXT', 'TEXT', 'STRING', 'text/plain;charset=utf-8', 'text/plain;charset=ANSI_X3.4-1968', 'text/plain']) 2012-07-31 10:56:43,919 process clipboard packet type=clipboard-request 2012-07-31 10:56:43,919 process clipboard request, request_id=10, selection=PRIMARY, local name=PRIMARY, target=STRING 2012-07-31 10:56:43,919 get_contents(STRING,<function got_contents at 0x10e9aa0>) 2012-07-31 10:56:43,930 got_contents(STRING, 8, <type 'str'>:4) data=[116, 111, 116, 111], str(data)=toto 2012-07-31 10:56:43,930 _do_munge_raw_selection_to_wire(STRING, STRING, 8, <type 'str'>:4) 2012-07-31 10:56:43,930 clipboard raw -> wire: ('STRING', 8, 'toto') -> ('bytes', 'toto')
r1234 fixes it for win32 clients too - this fix is in the 0.3.x and 0.4.x branches only as I will try to come up with a better solution for trunk (likely to be more invasive)
<lindi-> totaam: at least in my quick test the issue does not seem to occur anymore with r1319
ok, will follow up in #176 with backports for 0.3.x and 0.4.x branch.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/162