Community
Participate
Working Groups
Eclipse M4: reported error in many views while clicking. Without manually requesting deletion of anything, it deleted some entire directory end everything under it!!!! Don't ask how to reproduce, it has no tendency yet. It happend like 3 or 4 times yet, for totally obscure reasons. (I suspect out of memory since one of you told me it was a 64M max heap by default).
Has this happened again. It will be hard for us to fix it without more information. There is no other bug about it to say that has happened to more people.
yes! 3 times, on different depth in the src folder, but once AT the src, and I lost everything. I really suspect out of memory, since not many programmers try/catch these. try doing (heavy or not) refactoring while low on memory, provoque it by reducing the -J-mx##m interpreter args. You will see a lot of very incoherent reactions. I often get desynchronized package explorer like the file isnt there anymore, but is still in the editor? you know? I close the editor or try to switch to another from the package explorer but I get some more error dialog, then I may continue, but soon enought it will come again and gets worse. Of course, I better get out and restart eclipse. Now I use 2.0.1, the only stable (no no, not 2.0.2!). And I also start it "manually" with a -J-mx256M No bug until now. But I didn't try the 256 meg trick on M4, because I just don't trust it. I just can't afford to loose work again. Besides, none of the 2.1 series can decently run a 1.3 vm on 1.1.8 bootclasses anyway, so I need 2.0 (see bug 28120 Cannot launch debug with JDK 1.1.8 classes) Please, Please, fix both. There is no point to use another eclipse version than 2.0.1 if these 2 bugs are not fixed.
Please indicate: - which VM you are using to run eclipse - what VCM system you use, if any (CVS, ClearCase, or other) - whether UI operations you suspect cause the problem (you mention refactoring above) - are the files really deleted from the filesystem, or just not accessible via Eclipse?
ccing Erich due to mention of JDT actions.
eclipse runs in jdk 1.4.1 I don't control CVS from eclipse, although the project is over a CVS working folder I barely used the refactoring. But the bug really came after. There were no oparation else than trying to click folder and files in the package explorer and switching and closing editors. Files are actually DELETED! No kidding! That must be easy to find where file.delete is called no? unless it is moved somewhere magic I didn't see.
Moving to JDT-UI for comment on whether refactoring could possibly cause this behaviour.
IMO these errors are not caused by refactoring since refactoring usually shows a dialog prior to executing a refactoring (and this is not mentioned in the PR). There is only one exception where this is not the case: when you DnD a compilation unit to or from a default package. Did you do this ? Regarding file manipulation: refactoring only uses core.resources or jdt.core API to do any file manipulation. So if an out of memory error causes some problems here we should have a look at core.resources or jdt.core as well. I did some testing with low memory and I got exception during executing refactorings and other operations. But in all cases this didn't result in a loss of data. Filed separate bugs if necessary. The only "thing" I can think about that might cause any trouble are linked resources since they are new and some actions might not handle them accordingly. Did the workspace showing the behavior make use of linked resources ?
Never affirmed it was because of refactoring, I only say the data loss happened not long after it failed. It is clearly not enought to make it a cause. You should definitely look at the core, since it does look like any file based operation can cause the data loss. I don't know anything about linked resources. I obviously don't use them so. I should mention that my package explorer is often "inside" a folder with the "go into" feature. Could that in combination with file creation be unstable? Just this afternoon again, I did a refactor-move of a class and the package explorer wouldn't refresh to reflect the new location. I had to go out of the folder of the previous "go into" (go back). Then I saw it. Definitely a bug there.
But it was only a refresh problem? Did you lose data yesterday?
Stop looking at every little bit that could allow you to close the bug and start looking at every little bit that could be related to the bug. I'm giving you as much information I believe is pertinent. The refresh bug is one thing. No I didn't loose any data yesterday because I closed everyting to be sure it could not happen again. But if the internal paths structure were to be incoherent, that could be a cause of my previous data loss. It sounds like an obvious track to me. Start by grep-ing any file.delete or move. Are there any non-threadsafe internal file structure, race conditions from event handlers, etc...? You know better than me.
I am -not- looking for an excuse to close this PR. I was just trying to determine whether you lost data last time since it was unclear from your description. Looking at all occurrences of delete leads to -many- paths. It would help us greatly if you could try to come up with a reproduceable case, since you seem to be the only one encountering this, and it may have something to do with your particular setup.
Ok, sorry about my last reply. Some other guy in another context just pushed me a bit far. Ok. I was going to try to reproduce it on weekend at home, in a safer location. I will give you news as soon as I can. But my setup is very plain. Anyway we will see.
Thanks, we appreciate your help in tracking this down.
In the mean time, could that be related to bug 29745?
Bug 29745 was garbling files rather than deleting them, so it doesn't sound like it explains your symptoms. I'm looking over all references to delete, but haven't found anything yet.
Regarding your comments above about the relationship between views not getting updated properly and data loss, it's most unlikely that data would get lost just because a view does not update properly. The projects/folders/files in the workspace are kept in a separate workspace representation, with their content stored in the file system, not in memory. Access to the workspace is done purely through resource handles, which have no direct link to the underlying workspace representation (they're essentially just a path). Views like the Navigator and Package Explorer use these handles. If files are getting deleted, it's because somebody is explicitly deleting them. Unfortunateley, there are many callers to delete(), and the call chains fan out wildly. Could you provide a few more details to help me narrow my search: - Are you using just Java projects, or other kinds of projects too (e.g. simple projects)? - If using other kinds, have you seen data loss in them as well? - Do you modify files outside of Eclipse (directly in the file system). If you're using an external CVS, then you must occasionally do this. Did the data loss happen shortly after doing this? - Do you ever do an explicit refresh operation from within eclipse? Did the data loss happen after doing this? - Did the data loss happen immediately after opening a file? Immediately after a build? (It might be hard to tell the different between these two.) - What is the shape of your project: - what are the source folders and output folders? - is the output folder the same as the source folder (e.g. the project itself)? - were you changing these? - Although it doesn't sound like refactoring was the problem (you mentioned that the data loss occurred some time after refactoring), I'd still like to know the different kinds of refactorings you were using. I realize it can be hard to reconstruct the details, but any extra info will help in tracking this down.
I've tried looking at various senders of java.io.File.delete() and the delete methods in Core, without seeing anything out of the ordinary. Eduardo, would you be able to look into this?
Hey, As I suspect OutOfMemoryError, you have to look at any delete/rename inside finally clauses and finalizers, because most probably, the OutOfMemoryError is not caught and the code might complete the finally thinking it's ok to delete/rename. Still didn't get time to try reproduce. Soon I wish.
First. We consider loss of data a critical problem and we really want to fix it. Unfortunately it will be very difficult in this case to fix it without a reproducible case. Please try to reproduce it whenever you have the time. We appreciate your help. I looked in the senders of delete (we have lots) and did not find anything that could cause a DATA LOSS. I talked to Core to see if they had seen any PR like this but this is the only case. I think we can't fix the fact that Eclipse is crashing because of a OutOfMemory but it should not cause a loss of data and that must be fixed. Please if you have the time, could you answer Nick's questions.
(I though I did, maybe in personnal email...) - using just Java projects -I Do modify files outside of Eclipse (external CVS) but Data loss happened without any relation to that, at home I don't use CVS and I lost a folder for a small project. -Do you ever do an explicit refresh operation: yes, right click or F5. Not related. -Did the data loss happen immediately after opening a file. No -Immediately after a build? No. - what are the source folders and output folders? Single src root with packages, single output. -is the output folder the same as the source folder? No. -were you changing these? No. -the different kinds of refactorings you were using? certainly refactor rename, can't remember if I had one by refactor-move (it starting to a while now.) Please, let me try to reproduce first...when I get the time.
I have checked senders of delete again but did not find anything that could delete user files/folder. Have you tried a more recent build? Is this still happening? Have you noticed anything else that could help us fixing this?
We have been unable to reproduce this problem. Note that our freeze for RC1 is this Friday morning. Any help you can give us in tracking this down would be appreciated.
Kai recently reported a problem where if you do a large refactoring and run out of memory, then the workspace may be inconsistent due to some, but not all, of the files having been changed. But this is not so much a problem of data loss, as it is an interrupted change. DJ, do you know of any scenarios in Core where data could be lost due to OutOfMemoryErrors?
The only thing that I can think of would be if you were renaming a project. Consider the following: - call IProject.move() - we move the contents on disk - OutOfMemory occurs - we don't get the change to update the workspace tree In this case when you restart Eclipse I believe your source project would be closed (since its .project is missing) and there would be no workspace tree nodes at the destination project location. The work-around for this would be to create a new project with the same name as the destination project at the same location. This would bring all the project contents into the workspace tree. Note that this won't restore your properties, markers, syncinfo, etc. In Core we don't aggressively delete files on disk. We follow the philosophy of "the disk is right". So whenever we find an inconsistency between the workspace tree and the filesystem, we bring the filesystem changes into the workspace and do not delete anything from the filesystem. (the case that I mention above is a little different than a normal scenerio because we do not "discover" new projects on disk through a refreshLocal like we do with files and folders within a project)
Could this be related to bug 33726? Do you remember what was the name of the project you renamed, and what you renamed it to?
I also heard of a case where the project can be lost if you manually modify the .classpath file so that the output folder points to the project itself. This is not normally allowed in the UI, but they were not detecting the case when the file was directly modified. It would then clean the output folder, deleting all files in the project. Were you renaming the project, or making any modifications to the .classpath file (either directly or via some other tool)?
I never use the project folder as output. (I'm not disorganized enought to dare to do that anyway: got src, got output. Period.) Since february, it goes better as I never had the dataloss problem again...but only because I never let it a chance to occur. The main reason is that I now start eclipse myself, inside another console program. I used -Xmx128M and I periodically look at the Runtime.freeMemory from ny little console program. I ever growing above a hard 40 megs (cannot GC more), I quit and boot again, to see the same workspace in only 11 megs! I withnessed leaks in all versions up to now (otherwise, how bad is eclipse internal caching or how many soft references?) About caching and soft references, it's not because we defined 128meg heap that you are free to use it all: it is forcing swapping! Besides, GC pauses are HUGE, like 30 seconds to minutes. ADVICE, just in case you fdo that: NEVER call System.gc()! At least not on AWT event queue. This is a useless punition on the poor thread that called it. The JVM does GC by itself. Just consider putting the ref to null will suffice. For the dataloss bug, I would start investigating people around you for hidden fixes that were not documented. Some programmers may still think it is better to hide their mistakes rather than sharing it as a lesson. This bug was experienced before january 2nd. Since there was a very unstable streak since december 4 up to january 15, I would point fingers at post M4 and before. Sorry for not having time to stress-test again. But you know what "busy" mean for developpers...
Not clear what we can do hear for 2.1. We have stress-tested, and not seen data loss. When you lost data, did you get an Out of Memory error dialog, and then ask to continue (repeatedly)? We are considering forcing eclipse to exit (with a warning) if you run out of memory. If you continue after running out of memory, anything can happen.
HAPPENED AGAIN! Damn it! Ok. Let's stay calm. I use RC2, I spawn the jvm on the command line: C:\java\j2sdk1.4.1\bin\javaw.exe -Xmx128M -cp C:\java\eclipseRC2\startup.jar org.eclipse.core.launcher.Main org.eclipse.ui As you see: 128 megs of heap. I wasn't even close to run out of ram. And my eclipse hasn't been running for more than the day. What I did: I had only 4 files open, not much. I was double clicking a file in the package explorer, to open it. -->> I get Error activating view I tried to stop a running debug profile, barely clicking on the debug view and I also get -->> error activating view. Then I tried again the debug view and succeeded at terminating my process. I look at the error log view: could not find the file I just tried to open. (now I'm freaking out!) I look at the file system: the file is gone! not even in the recycle bin! I exit eclipse, before I loos more. Here the log part (not soo long), hope you have enought. !SESSION Mar 18, 2003 17:36:58.596 --------------------------------------------- java.version=1.4.1-rc java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments: org.eclipse.ui -install file:C:/java/eclipseRC2/ !ENTRY org.eclipse.ui 4 4 Mar 18, 2003 17:36:58.596 !MESSAGE Unhandled exception caught in event loop. !ENTRY org.eclipse.ui 4 0 Mar 18, 2003 17:36:58.606 !MESSAGE java.lang.NullPointerException !STACK 0 java.lang.NullPointerException at org.eclipse.jface.text.contentassist.ContentAssistant$Closer.focusLost(ContentAssistant.java:157) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:106) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:77) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:836) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:861) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:841) at org.eclipse.swt.widgets.Control.WM_KILLFOCUS(Control.java:3436) at org.eclipse.swt.widgets.Canvas.WM_KILLFOCUS(Canvas.java:205) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2791) at org.eclipse.swt.widgets.Display.windowProc(Display.java:2283) at org.eclipse.swt.internal.win32.OS.BringWindowToTop(Native Method) at org.eclipse.swt.widgets.Decorations.bringToTop(Decorations.java:196) at org.eclipse.swt.widgets.Shell.open(Shell.java:669) at org.eclipse.jface.window.Window.open(Window.java:553) at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:345) at org.eclipse.debug.ui.DebugUITools.launch(DebugUITools.java:493) at org.eclipse.debug.ui.actions.AbstractLaunchToolbarAction.run(AbstractLaunchToolbarAction.java:65) at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:251) at org.eclipse.ui.internal.WWinPluginAction.runWithEvent(WWinPluginAction.java:207) 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:77) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:836) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:1777) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1485) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1400) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1383) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:845) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:247) at org.eclipse.core.launcher.Main.run(Main.java:703) at org.eclipse.core.launcher.Main.main(Main.java:539) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at tools.ConsoleDebugger.a(Unknown Source) at tools.ConsoleDebugger.main(Unknown Source) !ENTRY org.eclipse.ui.workbench 4 2 Mar 18, 2003 17:38:40.219 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.ui.workbench". !STACK 0 java.lang.NullPointerException at org.eclipse.jface.text.contentassist.ContentAssistant$Closer.focusLost(ContentAssistant.java:157) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:106) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:77) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:836) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:861) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:841) at org.eclipse.swt.widgets.Control.WM_KILLFOCUS(Control.java:3436) at org.eclipse.swt.widgets.Canvas.WM_KILLFOCUS(Canvas.java:205) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2791) at org.eclipse.swt.widgets.Display.windowProc(Display.java:2283) at org.eclipse.swt.internal.win32.OS.SetFocus(Native Method) at org.eclipse.swt.widgets.Control.forceFocus(Control.java:595) at org.eclipse.swt.widgets.Control.setFocus(Control.java:1918) at org.eclipse.swt.widgets.Composite.setFocus(Composite.java:382) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart.setFocus(PackageExplorerPart.java:574) at org.eclipse.ui.internal.WorkbenchPage$2.run(WorkbenchPage.java:422) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:867) at org.eclipse.core.runtime.Platform.run(Platform.java:413) at org.eclipse.ui.internal.WorkbenchPage.activatePart(WorkbenchPage.java:419) at org.eclipse.ui.internal.WorkbenchPage.setActivePart(WorkbenchPage.java:2487) at org.eclipse.ui.internal.WorkbenchPage.requestActivation(WorkbenchPage.java:2214) at org.eclipse.ui.internal.PartPane.requestActivation(PartPane.java:331) at org.eclipse.ui.internal.PartPane.handleEvent(PartPane.java:311) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:77) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:836) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:861) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:841) at org.eclipse.swt.widgets.Shell.setActiveControl(Shell.java:835) at org.eclipse.swt.widgets.Shell.WM_MOUSEACTIVATE(Shell.java:1233) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2801) at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1225) at org.eclipse.swt.widgets.Display.windowProc(Display.java:2283) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:1294) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:73) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2839) at org.eclipse.swt.widgets.Display.windowProc(Display.java:2283) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:1294) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:73) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2839) at org.eclipse.swt.widgets.Display.windowProc(Display.java:2283) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:1294) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:73) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2839) at org.eclipse.swt.widgets.Display.windowProc(Display.java:2283) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:1294) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:73) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2839) at org.eclipse.swt.widgets.Display.windowProc(Display.java:2283) at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:1232) at org.eclipse.swt.widgets.Tree.callWindowProc(Tree.java:152) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2839) at org.eclipse.swt.widgets.Display.windowProc(Display.java:2283) at org.eclipse.swt.internal.win32.OS.PeekMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.PeekMessage(OS.java:1682) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1479) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1400) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1383) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:845) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:247) at org.eclipse.core.launcher.Main.run(Main.java:703) at org.eclipse.core.launcher.Main.main(Main.java:539) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at tools.ConsoleDebugger.a(Unknown Source) at tools.ConsoleDebugger.main(Unknown Source) !ENTRY org.eclipse.core.resources 4 368 Mar 18, 2003 17:38:42.292 !MESSAGE Resource /Outsight in resin/src/outsight/com/coradiant/outsight/Login.java does not exist. !ENTRY org.eclipse.core.resources 4 368 Mar 18, 2003 17:38:42.503 !MESSAGE Resource /Outsight in resin/src/outsight/com/coradiant/outsight/Login.java does not exist. !ENTRY org.eclipse.ui.workbench 4 2 Mar 18, 2003 17:38:46.589 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.ui.workbench". !STACK 0 java.lang.NullPointerException at org.eclipse.jface.text.contentassist.ContentAssistant$Closer.focusLost(ContentAssistant.java:157) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:106) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:77) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:836) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:861) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:841) at org.eclipse.swt.widgets.Control.WM_KILLFOCUS(Control.java:3436) at org.eclipse.swt.widgets.Canvas.WM_KILLFOCUS(Canvas.java:205) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2791) at org.eclipse.swt.widgets.Display.windowProc(Display.java:2283) at org.eclipse.swt.internal.win32.OS.SetFocus(Native Method) at org.eclipse.swt.widgets.Control.forceFocus(Control.java:595) at org.eclipse.swt.widgets.Control.setFocus(Control.java:1918) at org.eclipse.swt.widgets.Composite.setFocus(Composite.java:382) at org.eclipse.ui.part.PageBookView.setFocus(PageBookView.java:654) at org.eclipse.ui.internal.WorkbenchPage$2.run(WorkbenchPage.java:422) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:867) at org.eclipse.core.runtime.Platform.run(Platform.java:413) at org.eclipse.ui.internal.WorkbenchPage.activatePart(WorkbenchPage.java:419) at org.eclipse.ui.internal.WorkbenchPage.setActivePart(WorkbenchPage.java:2487) at org.eclipse.ui.internal.WorkbenchPage.requestActivation(WorkbenchPage.java:2214) at org.eclipse.ui.internal.PartPane.requestActivation(PartPane.java:331) at org.eclipse.ui.internal.PartPane.handleEvent(PartPane.java:311) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:77) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:836) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:861) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:841) at org.eclipse.swt.widgets.Shell.setActiveControl(Shell.java:835) at org.eclipse.swt.widgets.Shell.WM_MOUSEACTIVATE(Shell.java:1233) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2801) at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1225) at org.eclipse.swt.widgets.Display.windowProc(Display.java:2283) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:1294) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:73) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2839) at org.eclipse.swt.widgets.Display.windowProc(Display.java:2283) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:1294) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:73) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2839) at org.eclipse.swt.widgets.Display.windowProc(Display.java:2283) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:1294) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:73) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2839) at org.eclipse.swt.widgets.Display.windowProc(Display.java:2283) at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:1232) at org.eclipse.swt.widgets.ToolBar.callWindowProc(ToolBar.java:122) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2839) at org.eclipse.swt.widgets.Display.windowProc(Display.java:2283) at org.eclipse.swt.internal.win32.OS.PeekMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.PeekMessage(OS.java:1682) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1479) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1400) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1383) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:845) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:247) at org.eclipse.core.launcher.Main.run(Main.java:703) at org.eclipse.core.launcher.Main.main(Main.java:539) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at tools.ConsoleDebugger.a(Unknown Source) at tools.ConsoleDebugger.main(Unknown Source)
In case you wonder what is ConsoleDebugger, it simply invokes the main of the other program (eclipse) and listen to a tcp port for basic admin stuff, like memory info, call GC, (which I do a lot to help, and I see extremely long gc pauses! but that may be because of the 128 Meg heap...), see classpath, system props and threads, most core static stuff, on demand from the telnet client that would connect there. Don't worry, prooven to be good for years.
FYI the NPE below got fixed for RC3: org.eclipse.jface.text.contentassist.ContentAssistant$Closer.focusLost (ContentAssistant.java:157)
So, basically, you are telling me that, I double click Login.java, it gets deleted, I get error activating views, and nothing is logged... Obviously, eclipse has something to do with the deletion of my file, since I tried to open it. --- Some other silly observations, that I will tell you even if I think they are not usefull. -I use the logitech mouseware, where I can doubleclick with the middle button in a single click. I tried to open the file this way (I always double click with middle button). Do you expect 2 clicks? -my cvs work folder is my project folder. I filter out all "CVS/" from build output, and also from package explorer. I don't use eclipse CVS stuff. Could eclipse have some glitch with the presence of CVS stuff in the source folder? -my project file has a org.eclipse.team.cvs.core.cvsnature. Something I tried long ago to workaround the display of CVS folders, in the 2.0 times. But I got dataloss on projects that were not altered and not cvs nature at all. -I run caucho resin app server, it points to my output for classes, and my sources for... well...sources! Resin may read those files to compile but I disabled compilation. But the fact remains that while reading, maybe there is a file lock of some sort, colliding with yours. But then again, I got a dataloss on another project that do not involve resin, and there is almost chance that any eclipse process was running on it. -I have a ntp program that adjust time every 15 minutes. Generally does not adjust more than 300ms. At the time of the incident yesterday (around 17h38), it adjusted forward in time by 223ms and 39ms ntp v2 - time.nrc.ca - 123~18-Mar-2003~5:30:54 PM~0 223 ntp v2 - time.nrc.ca - 123~18-Mar-2003~5:45:54 PM~0 39
Still don't undestand what is going on here. Why do you use Xmx128M instead of Xmx256M? All messages in the news group recommend 256. I used to use 128 and notice that everything seems slower because GC had to run more frequently. What file system are you using? Are the files in your HD or in the network? Do the files you lost exist in the CVS repository? Which CVS client do you use? (PS: Why not eclipse?)
First, don't beieve everything you read in news group... hehehe. If you tell jvm to go up to 256 meg, it will! And your OS knows nothing about it so it will start swapping. (May I remind you that simple scrolling create megs of transient objects, even my winamp starts jitters!) My warmed up project space take about 20 megs, with a heap of about 40 megs: why would I inflict such a punition to my machine by climbing to 256 megs? If you project is so big the GC runs frequently, then it runs for smaller chunks. Basically, it means I should run back in 64 megs, but then I face Out of memory errors a bit too soon for my confort. I think some people should review their code about memory usage... anyway...back to main topic. No network files, I'm on hard disk, NTFS, with indexing service (like it matters...) >Do the files you lost exist in the CVS repository? >Which CVS client do you use? (PS: Why not eclipse?) What are you talking about? You think I'm an idiot, Edouardo? Hehehe... Of course the repository contains it. Besides, I mentionned that I got files and even entire folders deleted at home, where there is no CVS at all. As for eclipse as CVS: not just yet. No thanks. I'm very confortable with WinCVS 1.2, its text output and its tcl macros. Reliable. And I get to use my prefered external merger/diff tool (sorry guys but eclipse diff is ugly). We put effort into diagnosing and narrowing the context, let's try not enlarging it to unconfirmed premisses. Let me sum up: Top list of premisses: 1-bug occurs when you get an error activating views (involving at least the package explorer) 2-bug is not memory related 3-it deletes file or folder (with folder content if any) when it was the target of the selection 4-it is not CVS related 5-it is not related to project restructuration (moving src/output) 6-it is not related to refactoring If you confirmed or not other checkpoints, please log it here so others can feed on it. Thanks.
Another thing that would be helpful to know is, when your contents were deleted, were the latest changes preserved in the local history? That is, if you select the project (assuming it wasn't deleted as well) and choose Restore From Local History in the context menu of the Navigator or Package Explorer, does it have your most recent changes? It may have old changes, but if it has the latest changes then that suggests it's a regular resource deletion operation that's being invoked at the wrong time.
>were the latest changes preserved in the local history? >does it have your most recent changes? I have no clue... I never use that history. I will try to think about it next time. But I made no change to this file (the Login.java example) for months! So they (file, package and project) have no history at all at the moment I wrote this line.
Comment #29. My understanding is that -Xmx128M must be the last arguement, else it is ignored.
To #37, -Xmx option is a jvm option, not a org.eclipse.core.launcher.Main parameter! -Xmx has to be at least before the classname in C:\java\j2sdk1.4.1\bin\javaw.exe -Xmx128M -cp C:\java\eclipseRC2\startup.jar org.eclipse.core.launcher.Main org.eclipse.ui
What about the "error activating view" message mentioned first in comment #29? Usually there is a log entry showing which view could not be activated. You wouldn't get this message just because an editor could not be opened (I don't think). Next time you check the log it would be best to use Help/About Eclipse Platform/Configuration Details or the .log file in the file system. Also, in comment #34 item 2 says "bug is not memory related". Earlier comments suggested this was related to low memory situations. I guess this is no longer true, i.e., this is the first time you saw this problem and you didn't run out of memory? Did you get the "error activating view" message before? I wonder if these are two different causes of possibly the same bug.
Maybe 2 different cause. I can't remember for the first time, 4 months ago. For the last, you see all my last log session at that moment: Login.java could not be found, and the NPE from a plugin. For now I can tell you I use 2.1 final, and I still get popups for some "jface" errors. But haven't face the data loss bug yet. Note: the view I have open in my only perspective (customized debug): Debug, Breakpoint, thread and monitor, display, variable, package explorer, navigator, outline, expression, ant, tasks, console, errorlog, search, bookmarks. !SESSION Apr 22, 2003 14:56:41.333 --------------------------------------------- java.version=1.4.1_02 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments: org.eclipse.ui -install file:C:/java/eclipse2.1/ !ENTRY org.eclipse.jface 4 2 Apr 22, 2003 14:56:41.333 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jface". !STACK 0 java.lang.NullPointerException !ENTRY org.eclipse.ui 4 4 Apr 22, 2003 14:59:52.426 !MESSAGE Unhandled exception caught in event loop. !ENTRY org.eclipse.ui 4 0 Apr 22, 2003 14:59:52.436 !MESSAGE Argument cannot be null !STACK 0 java.lang.IllegalArgumentException: Argument cannot be null at org.eclipse.swt.SWT.error(SWT.java:2318) at org.eclipse.swt.SWT.error(SWT.java:2262) at org.eclipse.swt.widgets.Widget.error(Widget.java:385) at org.eclipse.swt.widgets.Text.insert(Text.java:828) at org.eclipse.jdt.internal.ui.preferences.JavaEditorHoverConfigurationBlock$3.keyReleased(JavaEditorHoverConfigurationBlock.java:194) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:124) 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.jface.window.Window.runEventLoop(Window.java:583) at org.eclipse.jface.window.Window.open(Window.java:563) at org.eclipse.ui.internal.OpenPreferencesAction.run(OpenPreferencesAction.java:53) at org.eclipse.jface.action.Action.runWithEvent(Action.java:842) 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:845) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) 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) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at tools.ConsoleDebugger.a(Unknown Source) at tools.ConsoleDebugger.main(Unknown Source) !ENTRY org.eclipse.jface 4 2 Apr 22, 2003 16:44:37.807 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jface". !STACK 0 java.lang.NullPointerException [few more times the jface error...]
The IllegalArgumentException apparently ocurred when you opened the Java editor preferences. Opened bug 36902 for that one. I doubt it has anything to do with the data loss problem or with the "error activating view" message.
Could you please include the stack trace for the NPE. The first stack is for an IllegalArgumentException, not an NPE.
I think the rest is just a repeat of the stack trace shown. It is interesting that there is a NPE stack entry with no other stack below it. That one happened separately from the IllegalArgumentException so the NPE stack trace would be helpful. I didn't even notice the first time I looked at it. Running on a different VM may produce better debug info.
I would love to give you the stacktrace, but there is none! I get repeatedly !ENTRY org.eclipse.jface 4 2 <<<<<<<<some date>>>>>>>>>>>>> !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jface". !STACK 0 java.lang.NullPointerException !ENTRY org.eclipse.jface 4 2 <<<<<<<<some date>>>>>>>>>>>>> !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jface". !STACK 0 java.lang.NullPointerException !ENTRY org.eclipse.jface 4 2 <<<<<<<<some date>>>>>>>>>>>>> !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jface". !STACK 0 java.lang.NullPointerException And since I run java instead of javaw, with C:\WINNT\SYSTEM32\CMD.EXE /k C:\java\j2sdk1.4.1\bin\java.exe -server -verbosegc -Xmx128M -cp c:\users\danny\prog\tools.jar;C:\java\eclipse2.1\startup.jar tools.ConsoleDebugger -st -1 -is 9090 org.eclipse.core.launcher.Main org.eclipse.ui I see the NPE without stack trace too. Note: could you beleive I saw a fullGC taking 29 seconds? Everything freezes during that time of course... I reported a RFE to javasoft JDC bug parade: they should use memory locking, (like memory+ does). I would gladly use some -Xml128 to pin the whole jvm in physical ram... I tried mempory+ and beside that it crashes the JVM (bug reported to TFI cny with no answer yet), eclipse was incredibly fast!
There was a posting on the newsgroup about a NPE in the Java console window. "From: "Nikolay" <N.Metchev@teamphone.com> Subject: NullPointerException Date: Thursday, April 24, 2003 11:53 AM I have started running eclipse using -vm arguements and I get a console window open in that console window I get the following messages from time to time: Unhandled exception caught in event loop. Reason: java.lang.NullPointerException Unhandled exception caught in event loop. Reason: java.lang.NullPointerException nothing shows up in the log and I am not sure when it actually happens. I was wondering if anyone else has noticed this?"
BTW: What does the -server argument do in the Sun VM? I'd try running without it to see if it solves your performance/GC problems. Also, you should try running without the ConsoleDebugger to see if the NPE goes away (probably won't make a difference but you want to be sure). E.g., just run Eclipse using eclipse.exe in which case the previous comment about putting -Xmx last on the command line holds true. You would specify the vm arguments using - vmargs -Xmx256M after the -vm argument. I would suggest specifying 256MB.
if I run just eclipse.exe I won't get any info if it crashe. I need the console. The ConsoleDebugger only invoke the main. It start a tcp socket server for a simple telnet console, where I can type in few commands like gc, memory info, date, system props, classpath. Totally safe, used for years now. using 256 meg won't solve anything. It will make it worse, forcing the stupid OS to swap even more, and cause a general whole "swap-me-in" just for GC. I rarely use above 40 meg java object heap (happyly returned from the console debugger, see how usefull...) -server causes the jvm to precompile every byte code, (as I read once in javaworld I think), it is like a JIT compilation only for everything on start. may make also some changes in native library for i/o performance but that is not confirmed. In general, I feel it runs smoother.
If you run eclipse with the argument -vm <you jdk path>\java.exe you will get a console that shows VM output. The console window will close when Eclipse crashes. However, that's fine since all I want to see is if Eclipse still crashes or not. We already know what's being printed to the console when it does crash.
Have you seen (or tried reproducing) this problem since April (the last comment on this bug report)? Or does it look like its gone away?
Hasn't happened again. Hope it is fixed for good. Somebody got lucky and escaped finger pointing. Thanks to all who invested times on this Damocles sword.
Please reopen if it happens again.
