[Richly]

I hate to file a bug report as uninformative as this one, but the problem I’m experiencing is this: sometimes I cannot save Matisse .java and .form files. No matter what I do — click File -> Save, press Ctrl-S, or close and respond Yes when asked if I want to save — nothing happens, not even an error message. The asterisk that indicates that the file has been modified does not clear. When I eventually quit Eclipse, whatever changes I’ve made seem to disappear. However, if I reopen Eclipse and try to redo some of the changes — e.g., rename a button — I may be told that I cannot have two with the same name. But if I do it again, the error message goes away, and I can rename the variable. However, I may not be able to save the changes.

This seems to happen when I make changes to a Swing control, e.g., remove it, rename it, or maybe add a new one. However, I cannot be sure that I’ve figured out relevant conditions that determine when this does or does not happen.

It is very discouraging to lose all my work when a form can’t be saved! I end up opening the form in NetBeans and using Matisse there to make the same changes I just made using Eclipse. So far, the problem has not occurred using Netbeans.

Has anyone else experienced this?

I’m using MyEclipse 5.0.1 GA & java 1.5.0_08-b03 on a Windows 2000 SP4 machine.

Anyone have any suggested workarounds?

Thanks,
– Richard

[Riyad Kalla]

Richard,
I am so sorry you had to run into such an obnoxious problem. First let’s get the formalities out of the way. Can you paste the result from MyEclipse > Installation Summary > Installation Details here for me?

Also, when you said there was no error message, did you mean in your log file? (<workspace dir>\.metadata\.log), if not, I’d like you to check that file now for exceptions or errors that could shed some light on what was happening.

Also, is this file under source control? If so, what kind?

How reproducable is this problem either with the existing form or with a new one? Can you reproduce it right away, does it take a few minutes, is it completely random?

If the problem *is* easily reproducable, can you create a new workspace (File > Switch Workspace > C:\tempworkspace, hit OK to restart) and try and reproduce it… does it reproduce?

It’s really important you answer each of the questions above so we get a good idea of the big picture here.

[Richly]

Hi. Thanks for your response. Here are your questions with my answers.

paste the result from MyEclipse > Installation Summary > Installation Details

*** Date: Wed Nov 01 20:48:41 EST 2006

*** System properties:
OS=Windows2000
OS version=5.0
Java version=1.5.0_08

*** MyEclipse details:
MyEclipse Enterprise Workbench

Version: 5.0 GA
Build id: 20060805-5.0-GA

*** Eclipse details:
MyEclipse Enterprise Workbench

Version: 5.0.1 GA
Build id: 20060810-5.0.1-GA

Eclipse Platform

Version: 3.2.1.r321_v20060921-b_XVA-INSQSyMtx
Build id: M20060629-1905

Eclipse RCP

Version: 3.2.1.r321_v20060801-2ekW2BxmcpPUOoq
Build id: M20060629-1905

Eclipse Java Development Tools

Version: 3.2.1.r321_v20060905-R4CM1Znkvre9wC-
Build id: M20060921-0945

Eclipse Plug-in Development Environment

Version: 3.2.1.r321_v20060823-6vYLLdQ3Nk8DrFG
Build id: M20060921-0945

Eclipse Project SDK

Version: 3.2.1.r321_v20060801-tQ1w49KnTArT0FZ
Build id: M20060921-0945

Eclipse Graphical Editing Framework

Version: 3.2.0.v20060626
Build id: 20060627-0816

Eclipse startup command=-os
win32
-ws
win32
-arch
x86
-launcher
C:\Local\eclipse320\eclipse.exe
-name
Eclipse
-showsplash
600
-exitdata
d9c_7c
-product
com.genuitec.myeclipse.product.ide
-vm
C:\Program Files\Java\jre1.5.0_08\bin\javaw.exe

Also, when you said there was no error message, did you mean in your log file? (<workspace dir>\.metadata\.log)

No. I’d not realized the log file existed (partly because it is associated with the directory that has the .code files, which is quite separate from the .java and .form files). I have now looked there and find several reports of files that could not be saved. I’ll include the most recent here.

!ENTRY com.genuitec.eclipse.dehory 4 4 2006-11-01 10:32:56.765
!MESSAGE Cannot save the form
!STACK 0
java.io.IOException: Cannot save the form
    at org.netbeans.modules.form.FormEditorSupport.saveDocument(FormEditorSupport.java:251)
    at com.genuitec.eclipse.dehory.DeHoryFormEditor.doSave(DeHoryFormEditor.java:88)
    at com.genuitec.eclipse.dehory.DehoryEditor.doSave(DehoryEditor.java:656)
    at org.eclipse.ui.internal.SaveableHelper$1.run(SaveableHelper.java:131)
    at org.eclipse.ui.internal.SaveableHelper$4.run(SaveableHelper.java:252)
    at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:369)
    at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:313)
    at org.eclipse.jface.window.ApplicationWindow$1.run(ApplicationWindow.java:763)
    at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
    at org.eclipse.jface.window.ApplicationWindow.run(ApplicationWindow.java:760)
    at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2283)
    at org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOperation(SaveableHelper.java:258)
    at org.eclipse.ui.internal.SaveableHelper.savePart(SaveableHelper.java:136)
    at org.eclipse.ui.internal.EditorManager.savePart(EditorManager.java:1386)
    at org.eclipse.ui.internal.WorkbenchPage.savePart(WorkbenchPage.java:2995)
    at org.eclipse.ui.internal.WorkbenchPage.saveEditor(WorkbenchPage.java:3008)
    at org.eclipse.ui.internal.SaveAction.run(SaveAction.java:67)
    at org.eclipse.jface.action.Action.runWithEvent(Action.java:499)
    at org.eclipse.jface.commands.ActionHandler.execute(ActionHandler.java:119)
    at org.eclipse.core.commands.Command.executeWithChecks(Command.java:461)
    at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:424)
    at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:160)
    at org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(WorkbenchKeyboard.java:466)
    at org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboard.java:799)
    at org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(WorkbenchKeyboard.java:846)
    at org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindings(WorkbenchKeyboard.java:564)
    at org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$3(WorkbenchKeyboard.java:506)
    at org.eclipse.ui.internal.keys.WorkbenchKeyboard$KeyDownFilter.handleEvent(WorkbenchKeyboard.java:122)
    at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
    at org.eclipse.swt.widgets.Display.filterEvent(Display.java:982)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:927)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:937)
    at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:965)
    at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:961)
    at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1275)
    at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:3346)
    at org.eclipse.swt.widgets.Control.windowProc(Control.java:3246)
    at org.eclipse.swt.widgets.Display.windowProc(Display.java:4025)
    at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
    at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1925)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2966)
    at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914)
    at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878)
    at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419)
    at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
    at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95)
    at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336)
    at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
    at org.eclipse.core.launcher.Main.run(Main.java:977)
    at org.eclipse.core.launcher.Main.main(Main.java:952)

Also, is this file under source control? If so, what kind?

Not yet. Some of the others in the project are under SVN (using TortoiseSVN), but this particular package is still flying below source control radar.

How reproducable is this problem either with the existing form or with a new one? Can you reproduce it right away, does it take a few minutes, is it completely random?

So far as I can tell, it’s pretty random, which is why I said initially that I hated to make this bug report. I spent about an hour trying to make the bug happen on something smaller than the full workspace (which includes a database that I’m not able to share), but I was unsuccessful. I might have been just as unsuccessful with the full workspace, too. If you like, I can give you a slightly simplified copy of the form that wouldn’t save, with some of its code removed. But who knows if the problem was related to the removed code? If you want this, please tell me how you want me to transfer it.

Again, thanks.
– Richard

[Riyad Kalla]

Richard,
Is your workspace or directory when the save failed on a network drive or is it local? Do you run real-time virus or spyware scanners? (namely anything that can legally interfere with the read/write of a file to the disk?)

Also have you tried rebooting and running chkdsk on your drive to see if there are any drive errors? The exceptions from the log file is very generic… almost implying that the file could *not* be written to the disk for some odd reason, that’s why I’m curious about the low-level state of the machine/scanners/harddrive/etc.

[Richly]

Hi. I was afraid this wasn’t going to be easy!

Is your workspace or directory when the save failed on a network drive or is it local?

It’s a separate directory, but it’s on the same local drive (C:) as the sources and Eclipse itself.

Do you run real-time virus or spyware scanners? (namely anything that can legally interfere with the read/write of a file to the disk?)

Yes, I run the free version of AVG, but I don’t think it checks files as they are written.

Also have you tried rebooting and running chkdsk on your drive to see if there are any drive errors?

I haven’t tried this, but I doubt it could be the problem. (Of course, it still could be; such doubts often cause us to ignore the actual problem.) I assume you’re asking about bad spots on the hard drive. If there were any, I think that Apricorn’s SMART-ER would be reporting problems, and it doesn’t. Also, there is over 45GB of free space on the drive, so it’s not a matter of a write that fails for lack of space. Note that I can copy the file, make changes in NetBeans and write it back, at which point MyEclipse is able to deal with it again. I just checked and noticed that my NetBeans is set up to use Java 1.6 while MyEclipse is using Java 1.5.

One thought is that my machine is pretty heavily loaded. I have 650 MB of physical memory and dual 500 MHz processors. With all the software I’m using, I have on occasion found more than 1GB in use (obviously swapping) while running MyEclipse. To improve performance, I try to turn off various things when I start up MyEclipse, but I can’t tell you now what the status was at the times when the files wouldn’t write.

When I get a chance, I’ll run CHKDSK and let you know the results.

– Richard

[Richly]

When I get a chance, I’ll run CHKDSK and let you know the results.

I checked the drive, and as I thought, there’s nothing wrong with it.

I should also report that I have MsMpEng.exe running, i.e., Microsoft’s Windows Defender. Again, since I can ultimately save the file both under NetBeans and then MyEclipse, and since I have no reports of detecting problems from Windows Defender, it seems unlikely that this is the reason.

Would it help if I forwarded you (privately) the entire .log file?

– Richard

[Riyad Kalla]

Richard,
The log file isn’t going to help because you already narrowed down the failure for me (and unfortunately the exception wasn’t hugely descriptive, doh)

I’ve filed an investigation issue for someone from the M4M team to try and reproduce this. Since we start debugging this problem how many other times has it occured?

[Richly]

The problem hasn’t occurred since we started, but to the extent I’ve had time to code, I have not engaged in the kind of development that seems to cause it to happen, i.e., I have not fiddled with the GUI. I’ve been busy making the buttons already on the forms do things that fill the fields already on the forms.
Let me know if I can provide anything that might help the M4M team.
– Richard

[Riyad Kalla]

Hmm, Richard I’m going to keep playing hard with M4M internally, we are in the QA phase for 5.0.3 and each time I work on verifying a bug is fixed in M4M I’m trying to break it with this in mind. If I find nothing, then let’s hope it was just a fluke.

The only remedy I can think of is to save very often so you notice it right away if it ever happens again and don’t loose much work. (that’s just a tip, not suggesting that is a good solution)

[Richly]

I’m now using MyEclipse 5.1 and the same problem persists. It’s making life quite miserable. What can we do to make fixing this likely to happen?

Here are the first few lines of the latest .log entry (you can have more if you ask).

!ENTRY com.genuitec.eclipse.dehory 4 4 2007-01-03 23:29:56.109
!MESSAGE Cannot save the form
!STACK 0
java.io.IOException: Cannot save the form
    at org.netbeans.modules.form.FormEditorSupport.saveDocument(FormEditorSupport.java:250)
    at com.genuitec.eclipse.dehory.DeHoryFormEditor.doSave(DeHoryFormEditor.java:88)
    at com.genuitec.eclipse.dehory.DehoryEditor.doSave(DehoryEditor.java:724)
    at org.eclipse.ui.internal.DefaultSaveable.doSave(DefaultSaveable.java:50)

[Riyad Kalla]

Richard,
Did this just start happening? Can you recover the file using the “Replace With > Local History” feature and rollback to a working version? Also did the break occur after a refactor operation? I’m wondering if the .form and .java file are out of sync now and one cannot be saved.

[Richly]

> Did this just start happening?

Yes, it just started, or maybe I should say, started again, since this first happening to me around the end of last October. I recovered by reloading from last night’s backup. I then added the button (successfully) by moving the project over to Netbeans 5.5. Now that I’ve moved it back, it behaves as it should.

One thing that may be related is that (as I reported in the M4M forum – see “Removing button or action breaks code”), I have had some trouble removing objects from M4M forms. To deal with the resultant corrupted files, I reloaded from the previous night’s backup. It may be that not refreshing the package after doing the restoration is related to this problem; I don’t claim to understand what “Refresh F5” does. Nor can I reconstruct the actual order in which things happened, so I’m not really sure that the failure to store happened after restoration. I just mentioned it in case it turns out to be relevant.

Best regards,
Richard

[Riyad Kalla]

I hate bugs like these, where they happen but not consistently, it makes testing and finding them a real problem. Let’s continue in your other thread and between your file and my test case see if we can discover a reproducable set of actions that break the form.

Also, longer term, we are planning a big refresh for M4M some time after our next release. But later this year.

[Tom Parry]

This sounds the same as another thread – but it seems to have been dropped?
I too had created a form using Matisse then opened the java version to edit the action performed methods. It seems to me that if I saved the java verison that this may contribute to the mismatching form.

Now I have an even stranger problem, I changed the form gui only – extended a JTextfield only in length. Saved the form. Then did a run – the application runs as per expected with the changed gui. Now I open up the form and it has gone back to its former version – where is it getting this crap from?

I looked in the log file and it too says it cannot save the form – but no other clue is there!
Should I start eclipse with -clean? Or is there a file to be deleted to not have the form find an older version!

[Riyad Kalla]

tparry,
Can you create a small sample project that includes this form and java file in it and compiles without errors, then export it to an archive and mail it to [email protected] ATTN Riyad so I can try and duplicate the situaiton on my end? Also please include a link to this thread so I have a reference to start from and let me know exactly what widget to change to try and break it.

[Author]

Posts