Eclipsed

Lately, when starting Eclipse, the JVM has failed to start.  A reboot of the system usually fixed the problem.  Until yesterday.  So I had to dig in and solve this problem.

I wanted to share my experiences with debugging this issue.

Added Note: This is not the bug by which Eclipse running under java 1.6u21 fails to pass the permgen size on to the JVM.  If you are running java 1.6u21 with Eclipse, don’t.

Determine why eclipse.exe is crashing with “-debug”

I edited my eclipse.ini and added the -debug option:


-startup
plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.0.200.v20090519
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
512m
-debug
-vmargs
-Xms100m
-Xmx752m

Then I ran eclipse.exe from the command-line, hoping to get a bit more information:

$ ./eclipse.exe
Error occurred during initialization of VM
Could not reserve enough space for object heap

Now that’s a clear error message!

I need lots of memory

You may have noticed some pretty large memory numbers in the eclipse.ini.  When Eclipse starts the JVM, it will allocate a little more than 1.2Gb (752M heap + 512M permgen).

I have many large C++ and JDT projects in my workspace.  I run classic Eclipse + CDT + svn plugins.  At one point I was having some memory issues and I blindly bumped up max heap and permgen.  This worked but I may have over-compensated by making them a bit too big.

So it’s memory.  Why did it used to work?  And how to debug it?

StackOverflow and vmmap

I found some useful information from Roland Illig on StackOverflow.  The JVM allocates a contiguous block of memory for its heap.  And a DLL with an improper base address could chop up memory such that I can no longer get that nice large chunk of memory.  Roland mentioned using the Microsoft SysInternals tool vmmap.exe to debug.

First I tweaked eclipse.ini, setting the highest possible max memory setting under which Eclipse would successfully start.   It turns out that this was 660Mb in my case.

Then I fired up vmmap.exe from SysInternals.  I selected eclipse.exe, and a memory map appeared.

I looked for a large segment of (yellow) Private Data.  I found one that was 1.2Gb, as expected.

Under Options, I turned on “Show Free Regions” so I could see any free regions.

Then I looked shortly after my Private Data for any Purple “Image” entries.  These are DLLs.  I noticed that there were 3 DLLs between my large allocation and about 200Mb of memory.  The DLLs had base addresses of 5ad70000, 5b860000, and 5d090000.

ListDlls

Now I just need to map the base addresses back to the DLLs.

By running listdlls.exe from SysInternals, I got a dump of all the DLLs currently running on my system, including their base addresses.  A quick search of this file dump revealed that the errant DLLs are uxtheme.dll, netapi32.dll, and comctl32.dll.

Solution: Rebase or Tune eclipse.ini

It turns out that on XP, these DLLs were rebased too low in XP SP2. One solution is to rebase these files to a more suitable address space.  Beware: this requires great care and knowledge.  I don’t really care to mess around with these unless I have to.

A safer approach is to tune my eclipse.ini settings to a more appropriate max heap size and permgen space.  I used jdk/bin/jconsole to attach to my eclipse process.  I determine I was using about 90M of permgen space.  So I have pared back my permgen space to 128Mb in eclipse.ini and things are working great again.  I will fire up jconsole again after Eclipse has been running for a couple days to determine if these values are OK.