Hard crash when building maven managed grails project

[ryanc]

I am experiencing a hard crash while running STS 2.2.1 on MacOS with two maven managed grails project in my workspace. The crash seems to occur when a build is %90+ complete and the entire application goes POOF. Sometimes an exception is found in .log and other times there is not a trace. This setup has been working fine for several days so I am guessing the crash is caused by something I added in the last day or so but so far have not been able to narrow it down.

Turning off auto build allows me to continue using the application but obviously that is not a great long term solution.

Any ideas are welcome!


Version: 2.2.1.200910210131-RELEASE
!SESSION 2009-11-11 13:11:47.598 -----------------------------------------------
eclipse.buildId=M20090917-0800
java.version=1.6.0_15
java.vendor=Apple Inc.
BootLoader constants: OS=macosx, ARCH=x86, WS=cocoa, NL=en_US
Framework arguments: -product com.springsource.sts.ide -keyring /Users/ryan/.eclipse_keyring -showlocation
Command-line arguments: -os macosx -ws cocoa -arch x86 -product com.springsource.sts.ide -keyring /Users/ryan/.eclipse_keyring -showlocation

!ENTRY com.springsource.repository 4 0 2009-11-11 13:11:48.892
!MESSAGE
!STACK 0
org.osgi.framework.BundleException: Exception in com.springsource.repository.internal.RepositoryBun dleActivator.start() of bundle com.springsource.repository.
at org.eclipse.osgi.framework.internal.core.BundleCon textImpl.startActivator(BundleContextImpl.java:806 )
at org.eclipse.osgi.framework.internal.core.BundleCon textImpl.start(BundleContextImpl.java:755)
at org.eclipse.osgi.framework.internal.core.BundleHos t.startWorker(BundleHost.java:352)
at org.eclipse.osgi.framework.internal.core.AbstractB undle.resume(AbstractBundle.java:370)
at org.eclipse.osgi.framework.internal.core.Framework .resumeBundle(Framework.java:1068)
at org.eclipse.osgi.framework.internal.core.StartLeve lManager.resumeBundles(StartLevelManager.java:557)
at org.eclipse.osgi.framework.internal.core.StartLeve lManager.incFWSL(StartLevelManager.java:464)
at org.eclipse.osgi.framework.internal.core.StartLeve lManager.doSetStartLevel(StartLevelManager.java:24 8)
at org.eclipse.osgi.framework.internal.core.StartLeve lManager.dispatchEvent(StartLevelManager.java:445)
at org.eclipse.osgi.framework.eventmgr.EventManager.d ispatchEvent(EventManager.java:227)
at org.eclipse.osgi.framework.eventmgr.EventManager$E ventThread.run(EventManager.java:337)
Caused by: java.lang.IllegalArgumentException: null source
at java.util.EventObject.<init>(EventObject.java:38)
at org.osgi.framework.ServiceEvent.<init>(ServiceEven t.java:112)
at com.springsource.repository.internal.RepositoryBun dleActivator.start(RepositoryBundleActivator.java: 77)
at org.eclipse.osgi.framework.internal.core.BundleCon textImpl$1.run(BundleContextImpl.java:783)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.framework.internal.core.BundleCon textImpl.startActivator(BundleContextImpl.java:774 )
... 10 more
Root exception:
java.lang.IllegalArgumentException: null source
at java.util.EventObject.<init>(EventObject.java:38)
at org.osgi.framework.ServiceEvent.<init>(ServiceEven t.java:112)
at com.springsource.repository.internal.RepositoryBun dleActivator.start(RepositoryBundleActivator.java: 77)
at org.eclipse.osgi.framework.internal.core.BundleCon textImpl$1.run(BundleContextImpl.java:783)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.framework.internal.core.BundleCon textImpl.startActivator(BundleContextImpl.java:774 )
at org.eclipse.osgi.framework.internal.core.BundleCon textImpl.start(BundleContextImpl.java:755)
at org.eclipse.osgi.framework.internal.core.BundleHos t.startWorker(BundleHost.java:352)
at org.eclipse.osgi.framework.internal.core.AbstractB undle.resume(AbstractBundle.java:370)
at org.eclipse.osgi.framework.internal.core.Framework .resumeBundle(Framework.java:1068)
at org.eclipse.osgi.framework.internal.core.StartLeve lManager.resumeBundles(StartLevelManager.java:557)
at org.eclipse.osgi.framework.internal.core.StartLeve lManager.incFWSL(StartLevelManager.java:464)
at org.eclipse.osgi.framework.internal.core.StartLeve lManager.doSetStartLevel(StartLevelManager.java:24 8)
at org.eclipse.osgi.framework.internal.core.StartLeve lManager.dispatchEvent(StartLevelManager.java:445)
at org.eclipse.osgi.framework.eventmgr.EventManager.d ispatchEvent(EventManager.java:227)
at org.eclipse.osgi.framework.eventmgr.EventManager$E ventThread.run(EventManager.java:337)

[ryanc]

Also it may be important to know this was occurring earlier today before I upgraded to 2.2.1 .

[Christian Dupuis]

ryanc,

the stacktrace can't have anything to do with your problem as it only happens once per startup and actually was fixed with the 2.2.1.RELEASE.

I have two questions though:

1. How did you update to STS 2.2.1 and from what?
2. What do you mean by "hard crash"? What are the symptoms?

Thanks for your help.

Christian

[ryanc]

Thanks for the quick response Christian.

I upgraded from 2.2.0 using the "Check for updates" feature in the "Help" menu. Please note this was occurring using 2.2.0 as well. I updated to 2.2.1 in hopes that it would fix this.

The symptoms I am seeing starts with a build of my project running in the background. I see 'Invoking maven builder' in the task view in the bottom right. There is a pause around 90-95% complete, and a few seconds later the entire application disappears (it is no longer running). I looked around in the .metadata directory but don't see anything in the logs.

Disabling automatic building appears to fix the problem (obviously because it is not building).

This is on Mac OS 10.6.

[Christian Dupuis]

ryanc,

if I understand you correctly, you are saying that your entire STS incl. JVM dies? Whoa, that is indeed a hard crash.

Could you check your Console.app for any crashes around the time when STS disappears?

Would be able to share the project with me? If yes, feel free to send it to me at christian DOT dupuis AT springsource DOT com.

Thanks, Christian

[ryanc]

I just enabled dependency resolution and auto build after having it off for a few days and it is no longer crashing. I will keep an eye on the console output should it happen again and email you the project.

[ryanc]

I experienced another hard crash today. This time I capture the console.app output (it is attached to this post) which looks like it might have some useful information.

It appears what happened was I had a groovy file called SpreadsheetBuilder.groovy that had a class 'Spreadsheet' in it. I copied the file and choose to name it Spreadsheet.groovy. So the groovy plugin automatically renamed the SpreadsheetBuilder class to Spreadsheet resulting in two classes with the same name in the same file. Seems like that was enough to send eclipse into oblivion.

[Andy Clement]

Hi,

Was the latest 'hard crash' the same as before - ie. STS disappears without a message? Any idea of you are running tight on memory?

I just recreated the scenario you described

Created com.foo.SpreadsheetBuilder.groovy containing

package com.foo;

class SpreadSheetBuilder {
}

class SpreadSheet {
}

I then Ctrl+C, Ctrl+V to copy paste it into the same package, called it SpreadSheet and got a similar sequence of problems as shown in your log.

However, no crash. I also see (because I see System.out in addition to what you are showing as System.err entries):

"Groovy Bug error thrown, but can ignore because likely to have been caused by existing syntax problems"

Now there is an issue there that we should not be throwing GroovyEclipseBug for this scenario as it isn't serious enough to warrant an exception (and the errors about duplicate classes get properly reported in the problems view anyway), but I'm not sure it is related to any hard crash.

I see at the end of your log:

11/20/09 Nov 20 2:16:20 PM com.apple.launchd.peruser.501[238] ([0x0-0x1aa1aa].org.eclipse.eclipse[16806]) Exited with exit code: 1

But I'm not a Mac guy so don't know what that means. Are you able to run the eclipse on a different JVM level to see if that changes the behaviour? Doesn't the Mac keep some kind of report somewhere of why something exits like that...

cheers,
Andy Clement
Groovy Eclipse Development

[ryanc]

Yes the hard crash was the same as before, STS just disappears. If I restart STS it immediate starts building when it starts up and but crashes before the build completes. Fixing the compile errors before starting STS allows STS to start normally.

I have had this happen to me with other groovy syntax errors. I just switched to the 1.6.5 compiler so I will keep an eye on it to see if that had any effect.

[Christian Dupuis]

tomrose,

would it be possible to get a project that shows this problem for you?

This would be extremely helpful as I'm not able to reproduce.

Christian