Bugzilla – Full Text Bug Listing
| Summary: | [Preferences] Some preferences are not crash safe | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Bryan Hunt <bhunt> | ||||||||
| Component: | Compendium | Assignee: | equinox.compendium-inbox <equinox.compendium-inbox> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | blocker | ||||||||||
| Priority: | P3 | CC: | alex.blewitt, alwyn.schoeman, andre_weinand, bokowski, bradleyjames, contact, daniel_megert, dj.houghton, dsciamma, eclipsebugzilla, eos.eclipse, frederic_fusier, hannes.stauss, joaoluispinto, krzysztof.daniel, leo.dos.santos, markphip, martinae, mayworm, michael.grosze, pedemont, pombredanne, railsgeek, support, tjwatson, Tod_Creasey, tom.schindl | ||||||||
| Version: | 3.3 | ||||||||||
| Target Milestone: | 3.4 M2 | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 215519, 215677 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Bryan Hunt
I had the same problem in my app, which was still in development so I did not report it (thought it was my bug). In my case, the problem happens on OSX, but not Windows. Basically, we are storing some data as preferences. This data was getting lost on restart on Mac. We added a specific call to the flush() method of our PreferenceNode and that resolved the problem. In 3.2 and on Windows, this is not necessary. In my case it influences User Libraries. I will add jars to the library and after the restart they won't be there anymore. This bug is not worthy of a 3.3.1 fix? We need to determine what is going on before we can commit to anything more than 3.4. I just lost my user library configurations again. Is there any information we can provide that will assist in identifying the cause of the problem? I suspect you specific problem may be JDT specific. Adding Martin to see if he has seen anything in anothe bug. No one seems to have addressed my comment, which could be a clue to solving the bug. We found that our OSX preferences were not saved unless we explicitly called the flush method on the preference node. The same code without the flush worked fine on Windows and also worked fine on Eclipse 3.2 OSX. I suspect places where stuff is getting lost do not call flush(). I recall when we were looking into this problem on our own app the JavaDoc indicated that while you did not have to call flush the behavior of the API could vary across platforms based on the implementation. My guess is that something changed on OSX in how this data is written to disk. I don't see this problem as JDT specific. Using my initial steps to reproduce, you can have a General -> Appearance preference disappear. User libraries are managed by jdt.core. Adding Frederic as cc. In your export file you should find keys starting with 'org.eclipse.jdt.core.userLibrary'. Can you have a look at your file to see if they are there? I agree with comment 5 (Mark) and comment 6 (Bryan): this issue does not seem specific to JDT or User Library preferences but more to Mac/OS system. Alwyn, may you confirm that your troubles with User Library preferences saving occurs on a Mac/OS box? Yes, I'm using Europa on a G4 Powerbook running Mac OS X 10.4.10.
> In your export file you should find keys starting with
> 'org.eclipse.jdt.core.userLibrary'. Can you have a look at your file to see if
> they are there?
>
Hi Martin,
Where can I find or how can I create the export file your interested in?
The export file created in step 3. I assume this was done with 'File > Export > Preferences', 'All preferences' Yes, I exported preferences using Export -> Preferences -> All preferences. Just as a reminder, I can also change a preference, restart the workbench, and the preference change will be reset to it's previous (default?) value. I don't have a step by step to reproduce this problem. I'm hoping the reproducible steps will eventually lead to a common root cause. I exported my preferences and for some user libraries I have entries like this: /instance/org.eclipse.jdt.core/org.eclipse.jdt.core.userLibrary.Kiosk=\#\#<cp en try ignore>\#\# A lucky guess would be that it would think its a copy of an existing user library with the same name, but there is no other such userLibrary entry. I just need to note that I'm using a workspace that I've been using since eclipse 3.1.1 if that makes a difference. Another thing I've noticed is that when using Mylyn the focused package explorer view is correct, but it seems to forget all except 1 of the opened editors in the editor pane. Have to confirm if this is consistent across all tasks though. Not sure if this classifies as forgotten preferences... I'm having a similar problem, but with Team preferences, which might indicate the problem is with the platform and not with JDT in particular. I'm also using a Mac (running Europa), and the problem happens both in a G4 running 10.4.10 and an Intel running the same version. Ignore patterns added in Team->Ignored Resources are ignored between restarts. If you find it useful, I will be happy to attach my .metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.team.core.prefs Changing OS from Mac OS to Mac OS X as per bug 185991 I could have sworn I just experienced a case where my User Library settings would be gone just to return when I restart Eclipse, not sure how that can be possible. Will confirm if it happens again. One of our customers reports exactly the same symptoms as described here. It happens on Mac OS X. In this case it's not related to JDT. This is just an ordinary plug-in preferences that are not getting saved. This problem does not appear on Windows. Same as above, the plug-in just calls IPreferenceStore#setValue methods, without making an explicit call to flush or save. André, have you seen something like this? Is anyone even looking at this? This problem is literally responsible for dozens of problems with Eclipse 3.3 on OSX. If a problem like this happened on Windows I bet there would already be a 3.3.1 release. (Of course on Windows the problem would have been discovered before release). Just the latest place I can see this problem manifest. You can get the Schedule for the Synchronize view to "stick" on OSX. It also loses pinned Synchronizations. I am upping everything on this issue to maximum priorities. The problem warrants it, and I defy anyone to argue otherwise. I am not going to be a jerk and change the values back if you re-prioritize it but someone needs to look at this problem and address it. Here's some interesting info that appeared today in the eclipse-mac google groups: "But when I x out, the prompt appears, and the preferences are saved." Using my original testcase, if you quit Eclilpse by clicking the red window close button instead of using File -> Quit (Cmd Q), the preferences will be remembered. Could this be a problem related to the new native application launcher? I'm a fulltime Eclipse 3.3 user and I haven't experienced this problem. However, I do not export/import Eclipse preferences. So is export/import necessary to reproduce this problem? (In reply to comment #23) > I'm a fulltime Eclipse 3.3 user and I haven't experienced this problem. > However, I do not export/import Eclipse preferences. > > So is export/import necessary to reproduce this problem? > No, you can bring up the preferences dialog, change a preference, exit Eclipse, and the change will be forgotten. I don't have a reliable testcase that reproduces the problem this way. I have never exported or imported preferences before. Here is an example of a simple problem: Open Eclipse Move the Perspectives tab to a different location than it currently is - Right-click -> Dock on -> (Change to somewhere else, maybe even turn off the text) Exit Eclipse using Command + Q or Eclipse -> Quit Eclipse Restart Eclipse Notice that the Perspectives tab is back to it's original state. This was tried on two separate macs using no plugins, and trying the SDK and the Platform Runtime Binary for v. 3.3. I even tried the 3.4 Stream Stable Build and the Nightly Build: N20070817-0010. If you X out, the preferences are saved. Clicking the close button caused the settings to be saved for me too! Andre, the problem can be subtle. You change a setting it works within your session but is gone when you close and restart. If you do not look for it you can miss it. Also it seems like the problem has to do with the preference store being flushed to disk so it could be that other things you do happens to trigger this. If you go back to comment #1, where I described the source of the problem, we discovered this by luck because we had an app storing data in the preference store and it was disappearing. We noticed the JavaDoc said it could behave differently on different platforms so we added an explicit flush() that previously had not been needed. Andre if you want to try to recreate it, put a project in the Synch view and use the view drop-down to set the Schedule. Then do File > Quit. When you reopen the schedule is gone. This is just one of main places where this Don't let the subtlety fool you. It can be a big deal. I use Ruby on Rails plugins, and I created 15 different rails servers for my projects under active development. As soon as I quit and restarted, they were all gone. Not very subtle. I've downloaded a fresh Eclipse 3.3, launched it with a new workspace, and tried all the different ways (discribed in this report) to reproduce the problem, but to no avail. Could you describe what you did for tests? I just had to rebuild my Mac after losing the hard drive so I also just reinstalled everything fresh. And I still get all the same problems I did before. I assume you saw this new wrinkle that if you close Eclipse by clicking the close button it works OK. I usually use Cmd-Q to close it and that appears to be one of the scenarios where the problem is triggered. I also dragged my Eclipse icon to the dock and launch from there. I assume you do the same, but given that you wrote a lot of this maybe you do something a bit different from the rest of us? Created attachment 76362 [details]
preference set
I tried Andre's experiment of downloading a fresh Eclipse and had difficulty reproducing the problem until I imported an existing preference set. Could the problem be triggered by a specific preference setting? I will attach my preference set, and the problem should be reproduced with the following steps:
Start Eclipse in a fresh workspace.
Import the preferences.
Exit Eclipse using Cmd-Q
Restart Eclipse
These preferences set the appearance to show only perspective icons and not text so the problem will be immediately visible. When you restart Eclipse, the perspective text labels will be back.
Could this be related at all to bug 194146? (In reply to comment #31) > Could this be related at all to bug 194146? This is very likely the cause - SWT calls System.exit directly. Ok, now I am able to reproduce the problem: If I toggle the "Show Text" setting on the perspective bar and use Cmd-Q to leave Eclipse, the setting is lost. If I close the window (which is what I normally do to quit Eclipse), the setting is stored correctly. So, yes this bug is most likely a duplicate of bug 194146. (In reply to comment #33) > Ok, now I am able to reproduce the problem: If I toggle the "Show Text" setting > on the perspective bar and use Cmd-Q to leave Eclipse, the setting is lost. If > I close the window (which is what I normally do to quit Eclipse), the setting > is stored correctly. > > So, yes this bug is most likely a duplicate of bug 194146. > I agree. This definitely seems like the same bug as 194146. Ok, if a preference guru (Tod?) can verify that preferences will not be properly saved if the BundleActivator.stop() is not called, we can mark this bug a duplicate of bug 194146. Assuming the preferences have not been otherwise saved that is the case - if you look at AbstractUIPlugin#stop() that is where we do our final preference save. having said that the question is more about whether or not the preference in question is being saved when it is set which is the best practise otherwise you can lose data in crashes. Bug 194146 would be a way to make this problem happen (as would killing the task in windows or the process on Linux) but it is generally a good idea to save your preferences after setting them anyways. We should find out which preferences are not doing this and log bugs to them seperately. I'll look into the Command Q issue and Bryans preference set in 3.3.1 as there might be some simple crash protection we can do. If it is too risky of a fix this might have to go to 3.4. I'll ask that people refrain from setting milestones when responding to bugs as this represents a commitment on our part to fix something and should be set by us. In this case we can look into it for 3.3.1. Renaming to reflect what we think the issue is. Tod and I have looked into this and it looks like it might be a bug in the preference code. There are a couple of API methods to import preferences and there is one that might not be saving them. We will investigate further. Also see bug 194146. Seems that SWT calls System.exit on the MAC, can that prevent the preferences from being persisted? I saw this was originally reported as a MAC bug, is this reproduced on other OSes? If you crash a Windows install by killing the process you will get the same effect. Yeah there are really 2 separate issues. This report covers a bug in the preferences where if you call a particular preference import API (the one that the UI is calling), the preferences aren't automatically saved. The other bug helps surface this bug by crashing Eclipse and not going through the normal shutdown life cycle. Fix released to HEAD. *** Bug 200059 has been marked as a duplicate of this bug. *** Did this fix also handle the case described in bug 200059? "When I use the menu system, Eclipse -> Quit Eclipse, or use Command + Q, some local settings are lost. For example, when I dock my Perspective list on the top left, quit and restart, it's back on the top right. The Confirm Exit prompt also does not show up." I assume it must since you already marked that as a dup of this bug. ;-) I believe your bug is a dup of bug 194146. I believe there is some concern with the fix being only for imported preferences - the original reason I reported the issue. Others are reporting that preferences set via the dialog are also not saved. Does the fix cover both cases? Ok, so it sounds like there are 3 problems: 1). problems with imported preferences -> covered by this bug report and fixed 2). problems on the Mac when exiting -> see bug 194146 3). problems with dialog preferences not being saved -> a new bug report should be opened for this against Platform/UI if one doesn't already exist. Thanks. *** Bug 206378 has been marked as a duplicate of this bug. *** Created attachment 86966 [details]
patch against 3.2.2
Here is a patch for the org.eclipse.equinox.preferences bundle against the code which is in the R3_2_maintenance branch.
Created attachment 87058 [details]
new pref JAR
Here is a new org.eclipse.equinox.preferences JAR file for people to try out.
Please add a comment here indicating whether or not your tests are successful.
Thanks.
Sorry, I should have mentioned that the JAR is built for 3.2.2. Verified that the new plug-in based on the patch works by 1. Open a new workspace with adopter product 2. Checked that Window > Preferences, J2EE, Use Ear Libraries classpath container is enabled. Pressed Cancel 3. File > Import, General > Preferences, .epf file 4. Checked that Window > Preferences, J2EE, Use Ear Libraries classpath container is disabled. Pressed Cancel 5. Restart adopter product 6. Checked that Window > Preferences, J2EE, Use Ear Libraries classpath container is still disabled. Pressed Cancel Before applying the patch, step 6 showed enabled. |