Eclipse (Kepler) periodically stops responding for some seconds

eclipsefreeze

Platform

I'm using Eclipse Kepler 4.3.2 (.M20140221-1700) on 64-bit Windows 7 Professional running on a Dell E6500 with 8GB RAM. Java VM is 1.7_u51. Java Auto Update is active as well as Windows Update.

Symptoms

They began on April 9th as far as I can tell. Everything had been working perfectly before. On editing some files (not all, but of several different types: .html, .php, .js, even .css) every once in a while Eclipse stops responding for several seconds.

There is some connection with the content assist, as invoking content assist with Ctrl-Space will trigger an immediate freeze in those files where freezing happens.

The .metadata/.log file reports an Out of Memory error, but I believe it to be a red herring – it is another symptom, not the real cause:

!ENTRY org.eclipse.e4.ui.workbench 4 0 2014-04-10 12:55:13.296
!MESSAGE 
!STACK 0
org.eclipse.e4.core.di.InjectionException: java.lang.OutOfMemoryError: Java heap space
    at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:63)
    at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:243)
    at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:224)
    at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
    at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:167)
    at org.eclipse.core.commands.Command.executeWithChecks(Command.java:499)
    at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
    at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:213)
    at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:285)
    at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:504)
    at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:555)
    at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:376)
    at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:322)
    at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:84)
    at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
    at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1262)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1056)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1081)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1066)
    at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1108)
    at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1104)
    at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1525)
    at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:4723)
    at org.eclipse.swt.widgets.Canvas.WM_CHAR(Canvas.java:344)
    at org.eclipse.swt.widgets.Control.windowProc(Control.java:4611)

Thinking initially that the problem was not enough memory, I increased Eclipse's heap size. This actually prolonged the freezing time.

Hypothesis so far

Something is happening that can be triggered by Content Assist, and causes an endless loop which leaks memory until the subroutine gives up. By increasing the available memory, I can make Eclipse spend a full minute before filling 4 GB RAM and giving up; and I can ameliorate the problem somewhat by decreasing the heap to 40 Mb, which takes only four or five seconds to abort (but I need a largish heap for other purposes, so that isn't a viable workaround, and however that's not how you solve a problem).

Attempts and investigations

  • April 8th, 2014, when the troubles began, was a Patch Tuesday. Around that time the following updates were pushed. None of these seems related to anything that might affect Eclipse; I tried rolling back 2922229 and 2929437 to no avail, then reinstalled them.

    • KB2928562 EFS related
    • KB2922229 MS14-019 relating to .BAT and .CMD.
    • KB2908783 iSCSI related
    • KB2929437 IE11 related
    • KB2830477 RemoteApp related
    • KB2800095 SmartCard related
    • KB2936068 MS14-018 IE11-related
    • KB2923545 Connection reliability in RDP 8.1
  • Disabling the Content Assist in the HTML and Javascript Editors by first disabling auto-activation and then unchecking all proposal types (Word, Template, Other Javascript) reduces the problem but does not solve it.

  • The normal voodoo technique of starting Eclipse in housecleaning mode, that used to fix the most baffling troubles (eclipse -clean -clearPersistedState) also availed little.

  • Clearing eclipse.ini did not yield results.

  • Monitoring file and network activity with FileMon/ProcMon/wireshark did not ferret out anything relevant.

Red Herrings

  • Heap size is not a solution, as detailed above.

  • I got another error that I'm not sure is related, "Error decoding problem identifier 1073741824". Being 0x40000000 in hex, it looks spurious to me. Anyway, Googling yielded nothing relevant, and including the original typo (it calls the number a problem idenfier instead of an identifier) reinforced my opinion that it's a spurious code.

Next Steps

The dearth of clues found so far makes me think I'm missing something really obvious, but before proceeding with the "scorched earth" strategy – completely remove Eclipse and reinstall afresh, and reimport all my projects – I decided to ask wiser heads than mine.

Meanwhile I'll try and remove all unnecessary and not-vitally-necessary plugins from Eclipse.

Failing all that, I think I'll have a shot at NetBeans 8.

Best Answer

Epilogue

As I had planned, I removed and reinstalled Kepler... with no effect whatsoever.

So, while setting up "Operation Scorched Earth", and therefore inventoring all the softwares I was going to have to reinstall, I noticed/remembered that I had also had a Java update more or less in the same time period.

So I:

  • removed again Kepler,
  • removed Java too,
  • ran a registry optimization (Pirisoft's CCleaner) which found all sorts of problems with my registry (which is usual for several shady "optimizers", and only happens in CCleaner when there's really something wrong; another good cleaner I can recommend is Auslogics').
  • reinstalled the latest Java update,
  • reinstalled Kepler
  • verified in eclipse.ini that I was using the new VM
  • reimported a project
  • tested it. So far so good...
  • reinstalled all the various plugins
  • reimported all other projects
  • tested them one by one
  • and this time, it worked!

Was it the update? Was it the registry cleaning? Could I have not set up the correct VM the first time over (i.e. my verification was actually a configuration change)? I don't honestly know.

Now I occasionally still have problems with the one project which is housed remotely (i.e. the files are accessed through a VPN). I'm quite sure it only means that Eclipse doesn't cope well with network latency. But no more freezes otherwise.

Related Question