Today, Eclipse crashed. The last entry in the log was:

Code:

java.lang.ArrayIndexOutOfBoundsException: 0 at com.genuitec.eclipse.jsf.facelets.FaceletsValidator.validate(FaceletsValidator.java:355) at org.eclipse.wst.sse.ui.internal.reconcile.validator.ReconcileStepForValidator.validate(ReconcileStepForValidator.java:339) at org.eclipse.wst.sse.ui.internal.reconcile.validator.ReconcileStepForValidator.reconcileModel(ReconcileStepForValidator.java:246) at org.eclipse.jface.text.reconciler.AbstractReconcileStep.reconcile(AbstractReconcileStep.java:96) at org.eclipse.wst.sse.ui.internal.reconcile.validator.ValidatorStrategy.reconcile(ValidatorStrategy.java:207) at org.eclipse.wst.sse.ui.internal.reconcile.DocumentRegionProcessor.process(DocumentRegionProcessor.java:192) at org.eclipse.wst.sse.ui.internal.reconcile.StructuredRegionProcessor.process(StructuredRegionProcessor.java:252) at org.eclipse.wst.sse.ui.internal.reconcile.DirtyRegionProcessor.run(DirtyRegionProcessor.java:610) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Is this a known bug or do you like more information?

Forgot: I'm using Eclipse 3.3 and ME 6.0M1

Aaron,
When you say crashed you mean process totally died, or you got the standard VM-crash popup from Eclipse? The reconcilers have never crashed the platform before, my guess is that something else happened.

It completely crashed but it might be related to an OOM bug elsewhere. I'm now running a memory monitor and will let you know when I find out what happened.

As for this bug, an easy way to provoke it is to create an empty HTML file (File -> New -> File -> test.html) and you should have one of those in your log.

Just tried test.html and test.xhtml using 6.0 GA and didn't get anything written to log.

Possible it could have been fixed.

Also if it was a OOM, it's possible it could be more than just heap and could be permGen space. Suggested args to start with here:
http://www.myeclipseide.com/PNphpBB2-viewtopic-t-10087.html

This seems to have been fixed in 6.0ga.

As for the OOM, I'm already running with 256MB permGen, 64MB CodeCache and 512MB heap. I still get OOMs but I haven't found a pattern, yet. I'll start a new thread when I find something worth reporting.

Aaron,
Glad to hear it's working better... as for the OOMs, do you have a lot of additional plugins installed besides MyEclipse? Is there a consistent set of actions that lead to the OOM? (e.g. Create new project, add caps, work with UML for a while?)

Riyad,

As I said, I couldn't nail it down, yet. I've enabled GC in the PermGen with

Code:

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

which helps. Besides ME, I have Groovy and Maven plugins installed. The usual pattern is switching between a Groovy-editor, a JSP-editor and JUnit tests written in Java and Groovy. Eventually, something will blow up but it's not as simple as "I run the JSP editor for 3 hours and it crashes."

ATM, I think I'll have to live with it. With my settings, Eclipse survives a few days, sometimes a week and with the memory monitor plugin, I get a pre-warning when memory gets tight. Usually, the VM runs out of Code Cache and ME warns me that less than 5% is left. Then, CodeCache is gc'd and the usage drops but somehow, the damage has already been done because stuff starts to fail (editors behave weird, JUnit forgets the last launch, etc).

Thanks for the additional flags... may try them in my personal workspace and see what happens (although I frequently restart during the day for testing/support reasons so may not notice a diff).

Notice that these flags are Java 6. They don't work with Java 1.5 and you'll get a strange "Can't start" error when you use them.