Comment 1 Philipe Mulet 2003-07-10 05:24:34 EDT

This is intended behavior. After a crash, we cannot trust our build state, and 
thus have to recreate it from scratch. The classfiles are just the output of 
the compiler, the build state remembers type/file dependency information.

The theory is that crashes should not be frequent. 

Comment 2 Etienne Juliot 2003-07-10 08:29:14 EDT

Theoricly, Eclipse souldn't crash. But is does (for example : with bug #24448).
But it isn't the problem here.

I disagree to say it's a standard behavior.

If the crash occurs during compile, I think it can be normal to re-compile project.
But if it crashes just during (for example) browsing help, or Eclipse's
preference, I don't understand why the build state is not good.

Perhaps just a refresh can be enough ?

Or, perhaps Eclipse can detect crash and ask to the user to re-compile all or not.

For us, it's the highest bug of Eclipse.

Comment 3 Philipe Mulet 2003-07-10 08:51:05 EDT

I am not questionning whether this is standard behavior or not, I am just 
explaining it is working as we intended it too. This doesn't mean we cannot 
change this.

The reason why the build state is lost, is that we did not get a chance to 
persist it, since Eclipse did not shutdown properly (and we save build states 
during shutdown). If we did save states at earlier stages, then we could do 
better, but saving states is quite expensive...

Need to think some more about it...

Comment 4 Etienne Juliot 2003-07-10 09:21:44 EDT

OK, sorry for the confusion between intended != standard.

So, you manage the build state only in memory and you persist it during the
window "Eclipse is closing ..." after shutdown.
Ok.

So, I try some proposition (have you other ?) :
- add a menu item to manually save build state
- allow automatic save build state, every X minutes, like an office application
- add an option to save build state after compilation, step by step (or
compilation by compilation), even if it's solwer (it's the user's choice)
- when CPU doesn't do anything during many minutes, save automaticly the build
state.


With this, you have some restore point. After crash, system can just refresh
source folder to see difference, or ask user to re-compile all.


Just another thing (perhaps a stupid one) : is it possible to catch some kind of
critical exception/error like OutOfMemoryError just before crash to save build
state ?

Comment 5 Philipe Mulet 2003-07-10 09:37:06 EDT

A build state reflects a certain state for resources. If we save it, and some 
resource modification occurs in the workspace, then it will be out of sync. 
Only a full build will be able to recover from it. So in theory, we would have 
to persist the information each time we build to be on the safe side, but this 
is quite painfull... as I said we can think about it.

As for the OutOfMemory question, once you reach an OutOfMemory you are fried. 
Any subsequent computation is likely going to fail.

Comment 6 Kent Johnson 2003-07-10 11:55:18 EDT

Since so many users can go months without ever crashing their development 
environment, why should their incremental builds be slower in the hope of 
reducing time IFF they crash? Why force them to wait 5-15 seconds numerous 
times everyday to 'save' 5-10 minutes on some non-existant day in the future?

Besides this issue cannot be reduced to saving the build state more frequently 
since the builder trusts the core's delta trees, etc. If the incremental deltas 
are not available because resource changes were lost due to the crash then we 
must do a full build regardless of when we last saved the build state.

The obvious solution is track down why you're crashing so frequently... and 
until then manually save your workspace every hour.

Comment 7 Etienne Juliot 2003-07-11 11:34:28 EDT

I'm sorry to repeat it, but Eclipse crash often (perhaps one time for 2 days).

It's perhaps we work on a big project. I don't know.
We don't use very exotic plugins, and it's crashing without any logic (it can
occur at any time, after any action).
"to 'save' 5-10 minutes on some non-existant day in the future?" : do know any
software without bug on earth ??  (except TeX :) ).


But this is not the subject (it's a newsgroup pb, I think).
If you want to think that Eclipse never crash (I hope it will soon with us
configuration), imagine it's the OS which crash.

A normal user will not understand why all his project is recompiled if all was
saved and already compiled before crash. In his mind, all was good and saved.
I understand very well your technical problem, but I speak about GUI impression.
I don't know any other software which done it (any IDE ?).

Imagine you work with a 3D modeler like 3DStudio (I have search a kind of
software with a long time of calculation) : you modelise, you ask for generation
your computer graphics, the CPU works ...., you save the result as a GIF, you do
 other thing, etc .... but, after couple of minutes, the software crash. When
you reopen this 3D modeler, you don't want to re-generate your image !!
I think Eclipse is near it, but the user's impression.


I agree with you to not force user to wait 5-10 seconds each time. 
That's why I completly agree with Philippe when he say that a complete reflexion
need to be done on this subject.

Comment 8 Kent Johnson 2003-07-11 11:57:52 EDT

What VM are you using?

What's the command line? Are you increasing the default parameters?

If the majority of your crashes are a result of running out of memory in the 
VM, then that is easily solved & is not an Eclipse bug, but a VM issue.

Comment 9 Etienne Juliot 2003-07-11 12:27:59 EDT

I use Sun JVM 1.3.1_01.
I am under Win 2000.

My command line is : 
eclipse.exe  -vm %JAVA_HOME%\bin\javaw -vmargs -Xmx256m

With Ant, I has have lots of out of memory errors due to bug #24448 .
Now, I call a .bat which call ant (!!!).
There are really less crash.

I am not alone to have crash at my entreprise : every engineer has some crash.
But I have done a typical configuration of Eclipse and we use same JVM, same OS,
and almost same PC.

Now, crash are not always Out of Memory error (I know this JVM bug, which is not
your fault -> JDK 1.5 with JMX might resolve it).
There is no typical raison.

When I will have a crash (or every of my colleague), I will send you log and
screenshot, and any info.

Now, here is my configuration detail :

*** System properties:
awt.toolkit=sun.awt.windows.WToolkit
file.encoding=Cp1252
file.encoding.pkg=sun.io
file.separator=\
java.awt.fonts=
java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment
java.awt.printerjob=sun.awt.windows.WPrinterJob
java.class.path=D:\prog\eclipse\startup.jar
java.class.version=47.0
java.ext.dirs=D:\prog\bea\jdk131\jre\lib\ext
java.home=D:\prog\bea\jdk131\jre
java.io.tmpdir=d:\commun\tmp\
java.library.path=D:\prog\bea\jdk131\bin;.;C:\WINNT\System32;C:\WINNT;D:\PROG\RATIONAL\RATION~1\NUTCROOT\mksnt;d:\prog\Perl\bin;D:\prog\oracle\ora81\bin;C:\Program
Files\Oracle\jre\1.1.7\bin;C:\Program Files\Compaq\Compaq Management
Agents\Dmi\Win32\Bin;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\Ca_Appsw;C:\TNGSD\BIN;C:\Program
Files\Fichiers communs\Adaptec Shared\System;D:\prog\Tcl\bin;C:\Program
Files\Unisys\Unisys Rose XML Tools\UML;C:\Program Files\Unisys\Unisys Rose XML
Tools\MOF;D:\prog\ULTRAE~1;d:\prog\Rational\ClearQuest;D:\cvsdata\lsprh\10_env\build;d:\prog\bea\jdk131\bin;d:\prog\Rational\common;C:\ORAWIN\BIN;
java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition
java.runtime.version=1.3.1_01
java.specification.name=Java Platform API Specification
java.specification.vendor=Sun Microsystems Inc.
java.specification.version=1.3
java.vendor=Sun Microsystems Inc.
java.vendor.url=http://java.sun.com/
java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport.cgi
java.version=1.3.1_01
java.vm.info=mixed mode
java.vm.name=Java HotSpot(TM) Client VM
java.vm.specification.name=Java Virtual Machine Specification
java.vm.specification.vendor=Sun Microsystems Inc.
java.vm.specification.version=1.0
java.vm.vendor=Sun Microsystems Inc.
java.vm.version=1.3.1_01
line.separator=

org.eclipse.jdt.debug.ui.scrapbookActive=false
os.arch=x86
os.name=Windows 2000
os.version=5.0
path.separator=;
sun.boot.class.path=D:\prog\bea\jdk131\jre\lib\rt.jar;D:\prog\bea\jdk131\jre\lib\i18n.jar;D:\prog\bea\jdk131\jre\lib\sunrsasign.jar;D:\prog\bea\jdk131\jre\classes
sun.boot.library.path=D:\prog\bea\jdk131\jre\bin
sun.cpu.endian=little
sun.cpu.isalist=pentium i486 i386
sun.io.unicode.encoding=UnicodeLittle
user.dir=D:\prog\eclipse
user.home=d:\profiles\ejuliot
user.language=fr
user.name=ejuliot
user.region=FR
user.timezone=Europe/Paris

*** Features:
standard ...

*** Plug-in Registry:
com.objfac.xmleditor (0.2.8) "XMLBuddy"
.... standard in Eclipse 2.1.1


*** User Preferences:
You want it ?


I just see an etrange log error. Perhaps it can help you :

!ENTRY org.eclipse.ui 4 4 juil. 07, 2003 16:00:08.890
!MESSAGE Unhandled exception caught in event loop.
!ENTRY org.eclipse.ui 4 0 juil. 07, 2003 16:00:08.906
!MESSAGE java.lang.StackOverflowError
!STACK 0
java.lang.StackOverflowError
	at org.eclipse.jface.viewers.StructuredViewer.getRoot(StructuredViewer.java:525)
	at
org.eclipse.jface.viewers.AbstractTreeViewer.doFindInputItem(AbstractTreeViewer.java:353)
	at org.eclipse.jface.viewers.StructuredViewer.findItem(StructuredViewer.java:350)
	at
org.eclipse.jface.viewers.AbstractTreeViewer.internalExpand(AbstractTreeViewer.java:798)
	at
org.eclipse.jface.viewers.AbstractTreeViewer.internalExpand(AbstractTreeViewer.java:810)
	at
org.eclipse.jface.viewers.AbstractTreeViewer.internalExpand(AbstractTreeViewer.java:810)
	at
org.eclipse.jface.viewers.AbstractTreeViewer.internalExpand(AbstractTreeViewer.java:810)
	at
org.eclipse.jface.viewers.AbstractTreeViewer.internalExpand(AbstractTreeViewer.java:810)
	at
org.eclipse.jface.viewers.AbstractTreeViewer.internalExpand(AbstractTreeViewer.java:810)

this line is repeated more than 300 times !!!
And after :

	at
org.eclipse.jface.viewers.AbstractTreeViewer.internalExpand(AbstractTreeViewer.java:810)
	at
org.eclipse.jface.viewers.AbstractTreeViewer.internalExpand(AbstractTreeViewer.java:810)
	at
org.eclipse.jface.viewers.AbstractTreeViewer.internalExpand(AbstractTreeViewer.java:810)
!ENTRY org.eclipse.debug.ui 4 5012 juil. 08, 2003 11:45:40.796
!MESSAGE Exceptions occurred attempting to step over the frame
!SUBENTRY 1 org.eclipse.jdt.debug 4 5010 juil. 08, 2003 11:45:40.796
!MESSAGE com.sun.jdi.VMDisconnectedException: Got IOException from Virtual
Machine occurred creating step request.
!STACK 0
com.sun.jdi.VMDisconnectedException: Got IOException from Virtual Machine
	at
org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply(PacketReceiveManager.java:145)
	at
org.eclipse.jdi.internal.connect.PacketReceiveManager.getReply(PacketReceiveManager.java:158)
	at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:173)
	at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:191)
	at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:206)
	at
org.eclipse.jdi.internal.ObjectReferenceImpl.isCollected(ObjectReferenceImpl.java:388)
	at
org.eclipse.jdi.internal.request.EventRequestImpl.addStepFilter(EventRequestImpl.java:408)
	at
org.eclipse.jdi.internal.request.EventRequestManagerImpl.createStepRequest(EventRequestManagerImpl.java:195)
	at
org.eclipse.jdt.internal.debug.core.model.JDIThread$StepHandler.createStepRequest(JDIThread.java:1798)
	at
org.eclipse.jdt.internal.debug.core.model.JDIThread$StepHandler.step(JDIThread.java:1753)
	at
org.eclipse.jdt.internal.debug.core.model.JDIThread.stepOver(JDIThread.java:1271)
	at
org.eclipse.jdt.internal.debug.core.model.JDIStackFrame.stepOver(JDIStackFrame.java:356)
	at
org.eclipse.debug.internal.ui.actions.StepOverActionDelegate.stepAction(StepOverActionDelegate.java:30)
	at
org.eclipse.debug.internal.ui.actions.StepActionDelegate.doAction(StepActionDelegate.java:25)
	at
org.eclipse.debug.internal.ui.actions.AbstractDebugActionDelegate$1.run(AbstractDebugActionDelegate.java:104)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69)
	at
org.eclipse.debug.internal.ui.actions.AbstractDebugActionDelegate.run(AbstractDebugActionDelegate.java:99)
	at
org.eclipse.debug.internal.ui.actions.AbstractListenerActionDelegate.runWithEvent(AbstractListenerActionDelegate.java:112)
	at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:241)
	at
org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:456)
	at
org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent(ActionContributionItem.java:403)
	at
org.eclipse.jface.action.ActionContributionItem.access$0(ActionContributionItem.java:397)
	at
org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent(ActionContributionItem.java:72)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:81)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:840)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:1838)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1545)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1402)
	at org.eclipse.ui.internal.Workbench.run(Workbench.java:1385)
	at
org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:858)
	at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461)
	at java.lang.reflect.Method.invoke(Native Method)
	at org.eclipse.core.launcher.Main.basicRun(Main.java:291)
	at org.eclipse.core.launcher.Main.run(Main.java:747)
	at org.eclipse.core.launcher.Main.main(Main.java:583)
!SESSION juil. 11, 2003 15:54:49.875 -------------------------------------------
java.version=1.3.1_01
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=fr_FR
Command-line arguments: -os win32 -ws win32 -arch x86 -install file:D:/prog/eclipse/


I hope it will help !!

Comment 10 Philipe Mulet 2003-10-28 04:34:03 EST

No action planned, crashes are severe, and full builds are on the safe side 
(though a bit painfull I agree).