Community
Participate
Working Groups
I am encoutering frequent crashes on startup when I open workspaces that are using CVS. The crashes occurs frequently but not predictable. I will attach a screenshot. The problem occurs on Eclipse 3.0 and 3.1 with CVS or SVN and without or without WTP. I also varied the JVM. It occurs with Sun 1.4.2_06, 1.4.2_09, and 1.5. I checked the .log but no messages are written to it. I can often work around the crash by simply trying again or by opening a new workspace and then switching to the real workspace. This often works but not always. Can you suggest how to debug this? My coworkers are not seeing the problem to it might be some conflict on my machine, hence difficult for you to reproduce. Therefore, any hints at how to debug the problem on my machine are appreciated. Thx.
Created attachment 29049 [details] Screenshot of Startup Crash Crash often occurs when I open a workspace under CVS control.
Usually, a VM will create a dump file when it crashes. I know the IBM VM does but I don't know about Sun's. If you can get a dump file, please attach it as it should help pinpoint the problem.
Michael, Thx for the tip. I've found a bunch of what look like JVM dumps. I'm attaching a few.
Created attachment 29097 [details] JVM Dump
Created attachment 29098 [details] JVM Dump 2
Created attachment 29099 [details] JVM Dump 3
David, I'm adding you on the cc list since the only WTP classes that appear in this JVM dump are from SSE. However, I've also seen the crash on vanilla Eclipse 3.1 so maybe this is an OSGi problem.
All the crashes come from the same VM (Sun 1.4.2_09-b05). There's nothing really helpful in the traces (i.e. it looks to me that all the crashes are VM crashes). I would suggest that you try a different VM in case the problem is specific to a VM. If the problem occurs with another VM and you are able to get a trace, feel free to reopen the bug with the traces.
Michael, As I mentioned, the crashed occured with Sun JDK 1.4.2_06 so I upgraded to 1.4.2_09 and still got crashes. Then I tried Sun JDK 1.5 and still got crashes. I will try another JVM and send dumps if possible.
Thanks for adding me Arthur, I love looking at dumps. But alias, I niether see anything "funny" in these. I'd also suggest adding more dumps periodically to this bugzilla, if continue to see with other VM's.
As requested, I've been running Eclipse 3.1.1 with Sun JDK 1.5 and I still get crashes. I am attaching yet another jvm dump for your viewing pleasure.
Created attachment 29529 [details] Sun JDK 1,5 Dump File Eclipse crashes when I open a workspace using CVS.
After the crash, I try again and the workspace opens. Go figure. This is kinda upsetting. Eclipse should not crash the jvm under any circumstance. AKAIK this only happens for workspaces that I have placed under team sharing, e.g with CVS. I happens with vanilla Eclipse and with Eclipse + WTP 0.7, and WTP 0.7.1. I really don't thingk this is a WTP problem.
As in one of the other previous dumps, the crash is happening in a VM thread. To me this looks like a VM issue. The fact that it happened for you with multiple VMs could mean it is an issue with your machine. Just so you know, there is not much CVS can do to crash a VM since it has no native code. Most crashes are caused by SWT but the traces that result from SWT crashes always happen in the main thread and indicate which system call was the culprit. As I said, your crash is happeing in the VM thread which is only running VM code. You may want to try a VM from another vendor. The problem could be a bug in multiple versions of the Sun VM or a problem with your machine. Trying a VM from another vendor would help identify one or the other.
I switched to the IBM JDK 1.4.2 and the startup crashes stopped. However, I just got a core dum after doing a CVS commit. The editors failed to repaint. I got core dumps whenever I tried to refresh an editor but the program didn't crash. I couldn't do anything useful so I had to restart. I'll attach the first core dump.
Created attachment 30114 [details] IBM JDK 1.4.2 Core dump
Headdumps were also created but they are 9 MB which I assume is too big to attach. I can provide them via ftp if that would help.
I looked at the stack trace and SSE is there. I was editing a large XML document. 1XMCURTHDINFO Current Thread Details NULL ---------------------- 3XMTHREADINFO "main" (TID:0x101EB9B8, sys_thread_t:0x2A1A20, state:R, native ID:0x358) prio=6 4XESTACKTRACE at org.eclipse.wst.xml.core.internal.document.DOMModelImpl.newModel(DOMModelImpl.java:586) 4XESTACKTRACE at org.eclipse.wst.sse.core.internal.text.BasicStructuredDocument._fireEvent(BasicStructuredDocument.java:496) 4XESTACKTRACE at org.eclipse.wst.sse.core.internal.text.BasicStructuredDocument.fireStructuredDocumentEvent(BasicStructuredDocument.java:1183) 4XESTACKTRACE at org.eclipse.wst.sse.core.internal.text.BasicStructuredDocument.setText(BasicStructuredDocument.java:2506) 4XESTACKTRACE at org.eclipse.wst.sse.core.internal.text.JobSafeStructuredDocument.access$1(JobSafeStructuredDocument.java:1) 4XESTACKTRACE at org.eclipse.wst.sse.core.internal.text.JobSafeStructuredDocument$2.run(JobSafeStructuredDocument.java:153) 4XESTACKTRACE at org.eclipse.wst.sse.ui.internal.editor.EditorExecutionContext.execute(EditorExecutionContext.java:43) 4XESTACKTRACE at org.eclipse.wst.sse.core.internal.text.JobSafeStructuredDocument.setText(JobSafeStructuredDocument.java:163) 4XESTACKTRACE at org.eclipse.wst.sse.core.internal.text.BasicStructuredDocument.set(BasicStructuredDocument.java:2364) 4XESTACKTRACE at org.eclipse.core.internal.filebuffers.ResourceTextFileBuffer.handleFileContentChanged(ResourceTextFileBuffer.java:444) 4XESTACKTRACE at org.eclipse.core.internal.filebuffers.ResourceFileBuffer$2.execute(ResourceFileBuffer.java:142)
Yes, I saw that there too :) And I did see an "out of memory" at the tome of the dump (though admit, I'm no dump file expert). So, while Eclipse shouldn't "crash" with out of memory ... increasing your memory might help get around the practical problem, until we get around to making our DOM Model smaller. (BTW, you might also turn off "quick diff" if you have it on ... I haven't looked recently, but in the past, its used quite a bit of memory). Are you launching from eclipse.exe? Hopefully, someone else can figure out how/why this might cause a crash, rather than the usual "out of memory, do you want to exit" message? )
Moving to WTP until the culprit of the dump is determined. If it is linked to CVS then by all means assign it back to Platform/CVS
Yes, I a launching with eclipse.exe using the -vm option. E:\wtp-0.7.1\eclipse\eclipse.exe -vm c:\ibm-java2-142\bin\java.exe Do you suggest another way to launch? I'll turn off quickdiff. I'm moving this to wst.sse. This problem occurred on 4 JVMs so I think it's our problem, not a JVM error. The only common link is CVS. The project uses SSH2 which requires cygwin. But that should be a seperate process. I've noticed this crash also without WTP, one once with SVN. Maybe SSE is just stressing the system and exposing an underlying problem.
I have investigated some, and believe I partially understand at least part of this problem. At least the part about crashes for "out of memory" errors, instead of the slightly friendlier dialog that says 'you've ran out of memory, we suggest you shutdown'. The basic problem is that some places in code, we (and the base Eclipse, bug 61963) catch Trowable or Error when they should not be. I'll writeup some guidelines for catching Error, open new bugs for us in WTP, and update this bugs 'depends' list with them, hence will assign to myself, even though many others will have to fix up their code.
David, Thx for the investigation. I guess I must be really stressing SSE editing those large W3C XML specs. Jeffrey - I added you for a couple of reasons. Can you cook up a stress test for SSE to create the out of memory condition? Not just a large document, but doing lots of edits too. Also, is it feasible to add a check in the API scanner to look for code that catches Error or Throwable? Sounds like we shouldn't be doing that in general if Eclipse has some standard recovery/dialog mechanism.
I feel this bug has run its course a long time to ago. Time to resolve.
.
