Community
Participate
Working Groups
Build ID: 3.3.0 I20070625 1500 Steps To Reproduce: 1. Open an x11vnc session with an already logged in X session (x11vnc -display :0) 2. Load eclipse 3. Use eclipse for a while, and right click on a few projects. 4. eclipse will quickly complain that it is out of memory and crash More information: 1. This has happened with any 3.x.x release I have tried 2. If I disable clipboard transfer, it never crashes in this way. 3. I am running the vnc client on Windows XP Pro SP2. 4. The vnc server is Ubuntu Feisty Linux.
Could you paste/attach a stacktrace or your log file?
Created attachment 79922 [details] Zipped log file during OOM
We need to either recreate the problem or insert debugging prints into the clipboard transfer to see how much memory is being requested. Duong will follow up.
The failure is in at org.eclipse.ui.part.ResourceTransfer.nativeToJava(). Are they asking for a huge buffer?
The problem doesn't appear to be in an SWT class. It appears to be an eclipse UI problem. Damien: Can you modify the ResourceTransfer class by applying the following patch? It will print the number of the resources that you're attempting to copy. The ResourceTransfer class can be found by checking out the org.eclipse.ui.ide project from CVS. Let me know if you need help in doing this. ******** patch start ************* ### Eclipse Workspace Patch 1.0 #P org.eclipse.ui.ide Index: extensions/org/eclipse/ui/part/ResourceTransfer.java =================================================================== RCS file: /cvsroot/eclipse/org.eclipse.ui.ide/extensions/org/eclipse/ui/part/ResourceTransfer.java,v retrieving revision 1.5 diff -u -r1.5 ResourceTransfer.java --- extensions/org/eclipse/ui/part/ResourceTransfer.java 8 May 2006 20:54:14 -0000 1.5 +++ extensions/org/eclipse/ui/part/ResourceTransfer.java 16 Oct 2007 23:07:16 -0000 @@ -158,6 +158,7 @@ new ByteArrayInputStream(bytes)); try { int count = in.readInt(); + System.out.println("ResourceTransfer: count=" + count); //$NON-NLS-1$ IResource[] results = new IResource[count]; for (int i = 0; i < count; i++) { results[i] = readResource(in); *********** patch end ****************
*** Bug 206552 has been marked as a duplicate of this bug. ***
Heya, Unfortunately, I haven't had the chance to do a recompile with this patch, would it be possible to put a jar attached to this Bug ? Cheers, Damien
This bug is still occurring as of Eclipse 3.7.2-1.
I also have this problem on startup of Eclipse CDT version 3.7.2, which can only be worked-around by disabling clipboard transfers in the VNC client (RealVNC). This is a real nuisance. java.lang.OutOfMemoryError: Java heap space at org.eclipse.ui.part.ResourceTransfer.nativeToJava(ResourceTransfer.java:162) at org.eclipse.swt.dnd.Clipboard.getContents(Clipboard.java:323) at org.eclipse.swt.dnd.Clipboard.getContents(Clipboard.java:241) at org.eclipse.ui.views.navigator.PasteAction$1.run(PasteAction.java:194) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:180) at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:150) at org.eclipse.swt.widgets.Display.syncExec(Display.java:4330) at org.eclipse.ui.views.navigator.PasteAction.updateSelection(PasteAction.java:189) at org.eclipse.ui.actions.BaseSelectionListenerAction.selectionChanged(BaseSelectionListenerAction.java:124) at org.eclipse.ui.views.navigator.RefactorActionGroup.updateActionBars(RefactorActionGroup.java:155) at org.eclipse.ui.views.navigator.MainActionGroup.updateActionBars(MainActionGroup.java:319) at org.eclipse.ui.views.navigator.ResourceNavigator.updateActionBars(ResourceNavigator.java:1412) at org.eclipse.ui.views.navigator.ResourceNavigator.createPartControl(ResourceNavigator.java:327) at org.eclipse.ui.internal.ViewReference.createPartHelper(ViewReference.java:375) at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:229) at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:595) at org.eclipse.ui.internal.PartPane.requestActivation(PartPane.java:263) at org.eclipse.ui.internal.presentations.PresentablePart.setFocus(PresentablePart.java:192) at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation$1.handleEvent(TabbedStackPresentation.java:94) at org.eclipse.ui.internal.presentations.util.AbstractTabFolder.fireEvent(AbstractTabFolder.java:269) at org.eclipse.ui.internal.presentations.util.AbstractTabFolder.fireEvent(AbstractTabFolder.java:274) at org.eclipse.ui.internal.presentations.util.AbstractTabFolder.handleMouseDown(AbstractTabFolder.java:344) at org.eclipse.ui.internal.presentations.util.AbstractTabFolder$3.mouseDown(AbstractTabFolder.java:78) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:191) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3588) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3209) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
*** Bug 380631 has been marked as a duplicate of this bug. ***
We can reproduce it on RHEL 5.8 and Eclipse 3.7.2 64 bit * start with a clean system: freshly rebooted linux system * start x11vnc * start Eclipse * perform any copy/paste operation (some text) inside your vnc client * operate the context menu in the project explorer in Eclipse * Eclipse get OOM Either it is a programming defect on Eclipse side (wrong pre-condition / wrong assumption about the clipboard content) or an issue of the clipboard data objects delivered by x11vnc. In detail, Eclipse assumes that the clipboard content describes a bunch of selected "resources" (files) and misinterprets the binary format. This leads to a high random integer number of Resource objects being created and leads to the out of memory situation (the first four bytes of the clipboard content are taken as integer value. This represents a positive or negative number up to 2^31). To workaround the problem, one can start x11vnc with command line options: -noclipboard and -nosetclipboard To fix the issue, org.eclipse.ui.views.navigator.PasteAction and all of it's derivatives (org.eclipse.cdt.internal.ui.cview.PasteAction, org.eclipse.ui.internal.navigator.resources.actions.PasteAction) should be fixed. The fix could be (not tested): change this: shell.getDisplay().syncExec(new Runnable() { public void run() { // clipboard must have resources or files ResourceTransfer resTransfer = ResourceTransfer.getInstance(); clipboardData[0] = (IResource[]) clipboard .getContents(resTransfer); } }); to this: shell.getDisplay().syncExec(new Runnable() { public void run() { // clipboard must have resources or files ResourceTransfer resTransfer = ResourceTransfer.getInstance(); // bute better to test it first if (isAvailable(resTransfer, clipboard.getAvailableTypes())) { clipboardData[0] = (IResource[]) clipboard .getContents(resTransfer); } } }); private static boolean isAvailable(Transfer transfer, TransferData[] availableDataTypes) { for (int i = 0; i < availableDataTypes.length; i++) { if (transfer.isSupportedType(availableDataTypes[i])) return true; } return false; }
*** Bug 252692 has been marked as a duplicate of this bug. ***
CQ:WIND00443016 We still see the problem with Eclipse 3.8.2 / CDT 8.2.0 on some Ubuntu 12.04 machines.
I had to resort to this: #!/bin/sh while true; do xclip -selection c -d :0 -o | xclip -selection c -d :0 sleep 1 done Problem "solved"
Interesting - thanks very much for this suggestion ! So with some background program, you read the clipboard selection and set it again every second. If that really improves things for Eclipse, it implies that xclip provides a "better" clipboard than whatever external application used to provide the clipboard and was not responsive ; and, it also implies that xclip can read the clipboard in a "better" way than Eclipse. For how long have you actually been using this workaround, and what are your experiences ? I'd assume that it resolves the problem to a maximum 1 second wait time ... have you seen any other side effects such as sometimes not being able to copy-and-paste ?
Folks, what is about solution from comment 11? All what we need is someone from platform UI team who can test and apply the patch. There is no black magic needed.
I have been using it for about a week now, Eclipse hasn't crashed once and I haven't seen any problem with the clipboard in any direction. I'm fully aware how horrible hack it is, just a workaround until a proper solution. (In reply to Martin Oberhuber from comment #15) > For how long have you actually been using this workaround, and what are your > experiences ? I'd assume that it resolves the problem to a maximum 1 second > wait time ... have you seen any other side effects such as sometimes not > being able to copy-and-paste ?
(In reply to Andrey Loskutov from comment #16) CQ:WIND00-WB4-51 I agree with Andrey. The issue is real, and the solution from comment 11 makes sense and should be applied. Could any committer step forward and merge the patch ? Or would submissions on Gerrit be required for IP signoff ?
I'm experiencing the issue in a VNC session to an Xubuntu 14.01.1 LTS box with Luna running via either openjdk or Oracle Java 8. I'm not using autocutsel, but I did notice that the parameters that x11vnc is launched with seem to be a factor. This results in the error: /usr/bin/x11vnc -xkb -auth /var/run/lightdm/root/:0 -nowireframe -wirecopyrect top -wmdt xfce -threads -repeat -rfbauth /etc/x11vnc.pass -shared -forever -rfbport 5900 -o /var/log/x11vnc.log This does not: /usr/bin/x11vnc -xkb -auth /var/run/lightdm/root/:0 -noxrecord -noxfixes -noxdamage -rfbauth /etc/x11vnc.pass -forever -bg -rfbport 5900 -o /var/log/x11vnc.log
Update: Ignore my previous comment. I was able to reproduce it with both settings. It seems that restarting x11vnc sometimes prevents the error from happening until eclipse has been restarting a couple times with new things in the clipboard.
OK, I have a patch and I've chosen different approach: limit the number of resources we can paste from clipboard. No one seriously would copy/paste or drag/drop more then 1.000.000 resources: only creating an *empty* array of 100.000.000 resources will cause OOME on 512 MB heap size (default for shipped Eclipse packages), same with copy/paste of a *full* array of 10.000.000 elements. The patch introduces a maximum limit for ResourceTransfer of 1.000.000 elements. In case the elements count exceed this limit, an error message will be logged to the error log and the transfer operation will be cancelled. JUnit test for the new limit is added too. Patch: https://git.eclipse.org/r/39996
Gerrit change https://git.eclipse.org/r/39996 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=60eeca78e4ac811794818181edb5a1fcc2af1c5b
Thanks Andrey, change looks fine to me. WHoever tries to copy 1000 000 items should now get a reasonable error message.
FYI, see bug 460069 for some JavaDoc work that needs to be fixed.
This causes a test failure in our official build, which reports a Javadoc issue: http://download.eclipse.org/eclipse/downloads/drops4/N20150216-2000/testresults/html/org.eclipse.releng.tests_linux.gtk.x86_64_8.0.html ==> http://download.eclipse.org/eclipse/downloads/drops4/N20150216-2000/compilelogs/platform.doc.isv.javadoc.txt ../../../eclipse.platform.ui/bundles/org.eclipse.ui.ide/extensions/org/eclipse/ui/part/ResourceTransfer.java:59: warning - #MAX_RESOURCES_TO_TRANSFER (referenced by @value tag) is an unknown reference. 1 warning
(In reply to Dani Megert from comment #25) > This causes a test failure in our official build, which reports a Javadoc > issue: > http://download.eclipse.org/eclipse/downloads/drops4/N20150216-2000/ > testresults/html/org.eclipse.releng.tests_linux.gtk.x86_64_8.0.html See https://bugs.eclipse.org/bugs/show_bug.cgi?id=205678#c24, we are solving this via Bug 460069.
(In reply to Lars Vogel from comment #23) > Thanks Andrey, change looks fine to me. WHoever tries to copy 1000 000 items > should now get a reasonable error message. I think the message could be further improved, in order to hint users to the specific problem with x11vnc. For example, on an embedded Yocto Linux 64bit system, I had been running into OOME with Luna, then later with Mars I got this in the errorlog (hyperlinks are to detailed system info + stacks from AERI): “Transfer aborted, too many resources: 1954115685” https://dev.eclipse.org/recommenders/committers/confess/#/incidents/55717524e4b018246752319d https://dev.eclipse.org/recommenders/committers/confess/#/incidents/55717524e4b018246752319e The error is only logged, but due to the Automated Error Reporting Initiative (AERI) it is still very visible and made me feel my install was broken. It was pure luck that I figured out comment 11 or comment 14 here could be used as a workaround. Any thoughts / ideas for a better error message ?
(In reply to Martin Oberhuber from comment #27) > (In reply to Lars Vogel from comment #23) > > Thanks Andrey, change looks fine to me. WHoever tries to copy 1000 000 items > > should now get a reasonable error message. > > I think the message could be further improved, in order to hint users to the > specific problem with x11vnc. For example, on an embedded Yocto Linux 64bit > system, I had been running into OOME with Luna, then later with Mars I got > this in the errorlog (hyperlinks are to detailed system info + stacks from > AERI): > > “Transfer aborted, too many resources: 1954115685” > https://dev.eclipse.org/recommenders/committers/confess/#/incidents/55717524e4b018246752319d > > https://dev.eclipse.org/recommenders/committers/confess/#/incidents/55717524e4b018246752319e > > > The error is only logged, but due to the Automated Error Reporting > Initiative (AERI) it is still very visible and made me feel my install was > broken. It was pure luck that I figured out comment 11 or comment 14 here > could be used as a workaround. > > Any thoughts / ideas for a better error message ? I suggest you open a new bug with a proposal.
*** Bug 449902 has been marked as a duplicate of this bug. ***
*** Bug 478144 has been marked as a duplicate of this bug. ***
*** Bug 366830 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/60609
(In reply to Martin Oberhuber from comment #27) > I think the message could be further improved, in order to hint users to the > specific problem with x11vnc. > [...] > Any thoughts / ideas for a better error message ? https://git.eclipse.org/r/60609 ?
I'm late to this party, but is the solution in comment 11 not workable? Looking at the OS X implementation of Clipboard#getContents, it looks like it has some protection to only pull out data if the transfer is compatible.
(In reply to Brian de Alwis from comment #34) > I'm late to this party, but is the solution in comment 11 not workable? > > Looking at the OS X implementation of Clipboard#getContents, it looks like > it has some protection to only pull out data if the transfer is compatible. This didn't worked out since the corrupted clipboard contain expected content type.
Gerrit change https://git.eclipse.org/r/60609 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=aae4f9a46fe0c9c405656cbf9c1ecf706cb62f6f
