Community
Participate
Working Groups
I20060627-1200 (and earlier) Not sure whether this is of any interest to you - feel free to close if not. I copied my entire installation to a new PC. Everything is identical (directory structure, file system, etc.). I was able to start most of my workspaces on the cloned machine, but not my standard head workspace. There, the core.resources plug-in fails to load with an exception very similar to the ones in bug 38682: org.eclipse.core.internal.dtree.ObjectNotFoundException: Tree element ...bin/.../Someclass.class not found. at org.eclipse.core.internal.dtree.AbstractDataTree.handleNotFound(AbstractDataTree.java:243) at org.eclipse.core.internal.dtree.DeltaDataTree.getData(DeltaDataTree.java:608) ... (stack trace made up) I was able to recover by deleting .metadata/.plugins/org.eclipse.core.resources/.snap. I believe I can reproduce the problem by copying the workspace from the original machine. If you are interested, I could provide the workspace in some form, or provide access to my machine for debugging... If not - fine with me. I know copying workspaces is not exactly supported.
Steve had the same problem after his workspace was moved to a different network drive (but the path was the same). Deleting the snap file also worked around the problem for Steve. This suggests to me the steps are: - Make changes in the worksapce (add/delete files) - Crash the workspace (.snap is deleted on a normal successful shutdown) - Move workspace - Restart Here was the stack trace in Steve's case: org.eclipse.core.internal.dtree.ObjectNotFoundException: Tree element '/Grant/win32/Main4$1.class' not found. at org.eclipse.core.internal.dtree.AbstractDataTree.handleNotFound(AbstractDataTree.java:257) at org.eclipse.core.internal.dtree.DeltaDataTree.getData(DeltaDataTree.java:585) at org.eclipse.core.internal.dtree.DataDeltaNode.asBackwardDelta(DataDeltaNode.java:50) at org.eclipse.core.internal.dtree.NoDataDeltaNode.asBackwardDelta(NoDataDeltaNode.java:59) at org.eclipse.core.internal.dtree.NoDataDeltaNode.asBackwardDelta(NoDataDeltaNode.java:59) at org.eclipse.core.internal.dtree.DataDeltaNode.asBackwardDelta(DataDeltaNode.java:47) at org.eclipse.core.internal.dtree.DeltaDataTree.asBackwardDelta(DeltaDataTree.java:88) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:816) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:792) at org.eclipse.core.internal.watson.ElementTree.immutable(ElementTree.java:517) at org.eclipse.core.internal.resources.SaveManager.restore(SaveManager.java:670) at org.eclipse.core.internal.resources.SaveManager.startup(SaveManager.java:1325) at org.eclipse.core.internal.resources.Workspace.startup(Workspace.java:1953) at org.eclipse.core.internal.resources.Workspace.open(Workspace.java:1716) at org.eclipse.core.resources.ResourcesPlugin.start(ResourcesPlugin.java:376)
*** Bug 151075 has been marked as a duplicate of this bug. ***
even without copying, just after a normal shutdown, this also happens for Build id: M20060921-0945 (Debian version: 3.2.1-4) removing the ".snap" file solves the problem, but in a bad way since all projects are gone. Another bug that talks about this painful experience is Bug 38682
Are you able to reproduce the issue on newer Eclipse version. Let's say 3.4.x or any 3.5 milestone version?
I am able to reproduce this issue using Eclipse 3.4.2. Like Ralf I did not need to copy the workspace from one location to another. I got the ClassNotFound exception after Eclipse had an abnormal shutdown. Upon restart I received the ClassNotFound exceptions and deleting the .snap file was the only solution.
Happened again:( the .java file it claims to be missing is exactly there :( org.eclipse.core.internal.dtree.ObjectNotFoundException: Tree element /privaLope/source/my/ShowKey.java not found. at org.eclipse.core.internal.dtree.AbstractDataTree.handleNotFound(AbstractDataTree.java:257) at org.eclipse.core.internal.dtree.DeltaDataTree.getData(DeltaDataTree.java:585) at org.eclipse.core.internal.dtree.DataDeltaNode.asBackwardDelta(DataDeltaNode.java:50) Suggestion: also mention the absolute path of the workspace you are looking for the file mentioned in ObjectNotFoundException
*** Bug 279766 has been marked as a duplicate of this bug. ***
I had a normal shutdown of version: 3.5.1.R35x_v20090910-9gEeG1_FthkNDSP2odXdThaOu9GFDPn83DGB7 Mainly using GWT. Deleting the .snap file fixed this for me and everything seems to be back to normal, all projects working and accounted for.
*** Bug 38682 has been marked as a duplicate of this bug. ***
Raising priority as per bug 38682
I am trying to find a root cause of this issue, but I cannot reproduce the issue on windows. All reports seems to be related to Linux, so I'd like to ask if anyone was able to reproduce this bug on Windows? The stacktrace is also interesting. SaveManager fails after the workspace tree (including delta trees) has been rebuild (!) and the last tree is being marked as the full one, while all previous are going to be stored as deltas. Copying workspace into different location is not relevant since all references are workspace relative. DataDeltaTree.getData will fail if the node was deleted, even intentionally. This leads us to DeltaDataTree.asBackwardDelta which seems to be buggy it returns always DataDeltaNode with data, but if the node was created in newer tree, then after making newer tree as root, the backward delta should have DeletedNode without content. DeletedNode itself handle this situation, where parent tree is copied, so it is transformed into DataDeltaNode.
Created attachment 155107 [details] The patch illustrating my previous comment Any opinions are welcome. I'll try to write some tests later (I hope) today.
(In reply to comment #11) > I am trying to find a root cause of this issue, but I cannot reproduce the > issue on windows. All reports seems to be related to Linux, so I'd like to ask > if anyone was able to reproduce this bug on Windows? The problem happened to Steve on Windows, but with the workspace on a network drive. It's possible the Java nio locking doesn't work in this case so it may be the same as the Linux case. Bug 38682 comment 7 describes my best guess at the cause for this. If this is always caused by multiple processes using the same metadata I think the solution lies in better locking, since as soon as multiple processes are operating concurrently on the same workspace you're going to end up with lost or corrupt metadata. Another possibility is at least detecting the metadata contention in this case. For example, detect that we are applying the snapshot to the *wrong* tree and just discard the snapshot in that case (a snapshot is a delta relative to some root tree, and if you are comparing to a different tree it is useless).
Is it possible that .snap file is damaged?
I'll answer, no its not possible. The exception happens because the first restored workspace tree, before applying deltas, is empty. And it is empty due to wrong C:\snap\workspace\.metadata\.plugins\org.eclipse.core.resources\.root\xyz.tree file, where xyz stands for version. In my case it is enough to rename that file from 188 to 186, and Eclipse starts fine :D. It looks like the file tree is first written down, and then the crash prevents workspace from saving correct number...
Technically it is possible that if Eclipse crashes in SaveManager#save line 1015 then the tree is written but the master table is not...
Created attachment 155331 [details] NaiveFix I think that in SaveManager#restore would be good to check if the tree is non-empty before applying snapshots.
John, any comments?
Can you explain what the fix is doing? I don't understand why it is looping 5 times and looking up the same location each time.
It does not check the same location. Actually (because of true flag) it checks a number of subsequent .tree files. If the .tree is not found, than we abandon changes, and throw the exception anyway. But if the .tree is found in reasonable number of iterations (arbitrary set to 5 in the patch) then we can assume that situation from comment 16 took place. In my testcase the difference between expected and actual file was 2, but I think it can grow to infinity.
Krzysztof, you told me that you are able to reproduce the issue locally. Please describe the steps so I could verify any potential fixes.
Defect CQ:WIND00205639 ER CQ:WIND00208995 Req CQ:WIND00165818 This is still marked target 3.6M7. Any updates? The biggest problem with this issue is that normal users cannot use their workspace any more, unless they are expert enough to delete the .snap file. I think we should (a) fail more gracefully, i.e. allow opening the workspace if at all posssible, and (b) log the error such that later analysis can detect if, when, where or how often such failover happened. I've had a look at attached patch, but like John I was confused. You're taking the tree for the current sequence number, and then you try looking at later ("future") sequence numbers. This seems odd. Wouldn't it make more sense to try looking at older sequence numbers? Or, is there any chance to throw away anything cached and rebuild the tree from scratch? The workaround from comment 0 just deleted the .snap file, can't we do the same in code? I also don't understand the arbitrary restriction to 5 sequence numbers. This is not relevant for performance, so why not look at all the trees we have got. The other question is, what could have crashed the workspace (and thus created the .snap file) in the first place. Can we do any better logging here? For instance, if a .snap file is found, try finding a hs_err*.pid to look for a backtrace.
Created attachment 165745 [details] .log from a crashed workspace Attached is the .log from our customer's crashed workspace. This was on a Windows host (I will attach the configuration file next), with the Workspace on a network drive (drive Z:). They claim that the workspace had never been moved, but the log does show "The workspace exited with unsaved changes in the previous session; refreshing workspace to recover changes."
Created attachment 165746 [details] configuration of host (WinXP) Unfortunately I don't have a full ZIP of the crashed workspace .metadata to investigate the trees.
I hope to look at it again during 3.6, however any help is welcome.
Update: I have a customer record of this problem happening with the workspace *not being moved* and located on a local drive: osgi.instance.area=file:/C:/WindRiver/workspace/ So, regarding John's comment 13 it looks like missing locking and/or multiple users accessing the same workspace is not the only case where this can happen. The customer logs do indicate "The workspace exited with unsaved changes in the previous session; refreshing workspace to recover changes." but apparently there was a different reason for exiting uncleanly in a way that destroyed the tree metadata so it could not be recovered on restart. This was with Eclipse 3.5.1. I know that the algorithms for saving workspace metadata *should* be such that they are always consistent even in case of an unclean shutdown, but it looks like there is a hole somewhere. While code review may be the only way finding that hole, I suggest considering ways for making recovery more robust. It's not acceptable that all of Eclipse doesn't come up any more on a restart because of this exception. At the very least I'd expect Eclipse to restore (with all workspace settings such as Preferences, dialog settings, etc) even if some of the projects can't be restored.
Created attachment 166297 [details] backtrace showing problem A user here just encountered this, this week with m6. Another possibility is that the user accidentally ran a Headless eclipse application concurrently with their running IDE. In our case it's very likely the problem occurred when the user opened the workspace using both the IDE and CDT's HeadlessBuilder. This didn't (until very recently) attempt to acquire the instance lock. What's odd is that the instance lock acquiring seems to be in IDEApplication#start(). The lock doesn't seem to be acquired by the workspace itself, or earlier in the startup process. The result is that every application must acquire the lock explicitly, right? Digging a bit deeper, I see that if you run AntRunner, say, which doesn't attempt to lock the instance lock, you can easily get into Workspace#open from multiple Eclipse instances concurrently. What's worse is that it seems impossible to lock the instance lock if the Application's plugin references core.resources. I just noticed this doesn't work correctly for HeadlessBuilder: I acquire the WorkspaceLock at the very beginning of HeadlessBuilder#start. Unfortunately Workspace#open is getting called first. HeadlessBuilder lives in cdt.managedbuilder.core. The ManagedBuildCorePlugin is started and happens to register an IResourceChangeListener => ResourcesPlugin#start() => Workspace#open(). The fact that referencing core.resources causes the Workspace#open to be called and there's no check that the instance lock is held by the current process, means its difficult to guarantee that applications don't accidentally open the workspace more than once.
Hm. I've tried to fix the CDT issue by tweaking the bundle activation policy: Bundle-ActivationPolicy: lazy; exclude:="org.eclipse.cdt.managedbuilder.internal.core" Unfortunately HeadlessBuilder references a number of core.resources interfaces still leading to core.resources activation on instantiation. Without a major refactoring this would seem non-trivial to fix. Perhaps this workspace locking should really be done by the platform?
I filed bug 310791 for the issue of headless IApplications causing ResourcesPlugin#start()=>Workspace#open() leading to potential concurrent access to the workspace tree. It seems that every IApplication (other than workbench) that references core.resources is vulnerable to this as the class & plugin-loading lead to core.resources being started before IApplication#start() is called. So even if a headless application attempts to lock the instance location, as the first thing it does (which few seem to), its too late by the time #start is called.
(In reply to comment #29) > I filed bug 310791 for the issue of headless IApplications causing * Bug 310793
Changed summary, previous value was: ObjectNotFoundException after copying workspace because I know for sure that this issue happened for a customer of ours without any kind of workspace move involved. I'm still very concerned about this issue, especially after getting confirmation from our customer that 1.) The workspace in question had never been copied. 2.) No headless applications had ever been used. 3.) While projects had resided on a remote Samba share, thehe .metadata had always resided local on C:\Documents and Settings\... 4.) So it is safe to assume that locking had always been proper. The thing that worries me most, is that Eclipse fails to open the workspace, although restoring the workspace is possible (by deleting the .snap file). Especially as long as we don't know for sure what is causing this issue, I strongly think that we should make every effort possible on startup to not just fail with the exception, but log the exception and try to repair the inconsistency.
Moving to 3.7 for further investigation.
Created attachment 170770 [details] Patch - different approach Work in progress. The patch will try to fix the inconsistency between master table and the .tree name. This is not tested, just shows my current approach. BTW. The problem is not triggered by workspace copying in my opinion. It is 'Save' problem where Master Table is out of sync with the actual .tree file name. This may happen if saving fails - because f.e. network drive had been disconnected.
Thanks for continuing this work! I actually had a very different idea for approaching this: What if, for a start, we just change the error message to something like: "We are sorry Eclipse failed to start due to an inconsistency in your workspace. Please zip up your (wsdir)/.metadata folder and attach the archive on https://bugs.eclipse.org/bugs/show_bug.cgi?id=149121 along with a description of your last steps when closing this workspace to help us investigate, understand and solve this problem. After zipping up your workspace, you can delete the (...)/.snap file in order to revert to the last known good configuration, such that your workspace should come up again. " Essentially, the idea is involving our end users in the analysis, since we are still a bit clueless as to what really triggers the issue. Has something like this ever done before at Eclipse? Does it sound acceptable, perhaps for an SR1 release?
Another user hit this, without opening the workspace concurrently. They think they closed the workspace on one machine, and re-opened it on another (both server use the same NFS mounts). So the cause could have been a NFS sync issue... (In reply to comment #34) > After zipping up your workspace, you can delete the (...)/.snap file The two times I've done this the workspace does open, but all projects are missing. Re-importing them loses some of the resource metadata such as which resources are derived. When you delete the .snap file, do you not also lose all the projects in the workspace?
James, if your user still has the workspace, can you have him zip it up? For my customer, this issue clearly happened on Windows without any NFS involvement on the .metadata (was on C:\) but the project content was on a remote samba share. According to comment 0, there seem to be at least some cases where deleting the .snap file recovered. But I've also heard other comments that the projects were lost when doing so. In fact my acceptance criterion for a workaround (until the original cause of this is found) is that we must avoid loss of data.
(In reply to comment #36) > James, if your user still has the workspace, can you have him zip it up? I'm afraid it was a couple weeks ago, and we didn't preserve the workspace. This is a very rare issue for us, but if/when it happens again, I'll be sure to tar it up for analysis.
.snap file contains recent modifications of the file, between two workspace saves. This issue is triggered by the lack of workspace state, on the top of which the .snap should be applied. This results in exception and prevents resources from starting. No other plugin (especially the product definition) cannot be started if it depends on plugin which failed to start. As I have said before: .snap file contains modifications to some resources, but workspace tree is empty. Deleting a .snap file brings the whole resources back to consistent, empty state. Therefore I do not believe that deleting a .snap file is a proper workaround. It is just a way of allowing Eclipse to start.
*** Bug 329610 has been marked as a duplicate of this bug. ***
*** Bug 329815 has been marked as a duplicate of this bug. ***
*** Bug 138102 has been marked as a duplicate of this bug. ***
I had couple of our users hit this issue as well. In our case it was on a windows machine with a pretty simple setup(workspace on local drive). However, in our case user had debugger connectivity issues with HW device they were debugging. They tried shutting down eclipse, but debugger prevented this from completing and user had to kill eclipse using task manager. This is definitely not a normal situation, but the end result was the same as in other cases listed above. User could not start eclipse and deleting .snap file allowed user to proceed. Is it possible to resolve this for Indigo? Is there additional information that you'd need?
(In reply to comment #42) > I had couple of our users hit this issue as well. In our case it was on a > windows machine with a pretty simple setup(workspace on local drive). However, > in our case user had debugger connectivity issues with HW device they were > debugging. They tried shutting down eclipse, but debugger prevented this from > completing and user had to kill eclipse using task manager. This is definitely > not a normal situation, but the end result was the same as in other cases > listed above. User could not start eclipse and deleting .snap file allowed user > to proceed. Is it possible to resolve this for Indigo? Is there additional > information that you'd need? Martin, are you able to reproduce your scenario each time? That is to create simple setup as you mentioned, simulate connectivity issues so that debugger hangs, try to close Eclipse without success, kill Eclipse using Task Manager, get ObjectNotFoundException when starting Eclipse?
> Martin, are you able to reproduce your scenario each time? That is to create > simple setup as you mentioned, simulate connectivity issues so that debugger > hangs, try to close Eclipse without success, kill Eclipse using Task Manager, > get ObjectNotFoundException when starting Eclipse? Unfortunately no. My attempts at duplicating the issue have failed so far. I am trying to see if the user is still able to reproduce this issue. I might be able to get the workspace that triggers the exception. However, this workspace was generated with an old version of Eclipse that has some custom modifications, thus I am not sure how much help it will be.
buildId: M20100909-0800 I have exactly the same issue. Eclipse reports: org.eclipse.core.internal.dtree.ObjectNotFoundException: Tree element '[...]/SimulatorTest.class' not found (the corresponding .java file was the last file edited and saved under Eclipse). But the file exists! Even if I remove the file and force its recompilation, that doesn't help. I can remove the .snap file, but it's not solving the problem - Eclipse crashes regularly with no reason. Earlier I had similar problem when I tried to commit very large binary file to SVN repository. It succeeded, but the next time I was starting Eclipse - it crashed reporting the commited file in ObjectNotFoundException.
Created attachment 190443 [details] An org.eclipse.core.resources workspace that crashes Eclipse 3.6 (RCP) In case no one has submitted a "broken" workspace with the problem .snap files, here goes. We got this from a user of our RCP app; it will generate the exception in Eclipse, or any app using org.eclipse.core.resources I imagine. I removed the project folders to reduce zip file size. It doesn't seem to matter where you put this, in terms of replicating the ObjectNotFoundException -- the original user path was c:\users\aaron\treeage\workspace
*** Bug 340367 has been marked as a duplicate of this bug. ***
Any update? This is one of the nastiest issues I'm currently aware of. Getting closer to a solution would be awsome. Even if that "getting closer" only employs adding logging facilities to get more data. Ideally the workspace attached by Andy has what's needed though...
Szymon P. has been investigating the issue. He will update the bug when he has anything to report.
I have gone through all related bugs and here are some facts about the problem: - 9 bugs marked as duplicate of this bug - problems occurs since 2003 (Eclipse 2.1) - both on Linux and Windows in different versions - workspace stored locally, no workspace moving - 11 users confirm that there was a crash or hard close (OOME, killall, power down) - 2 users claim there was no crash (but we cannot tell if the workspace was correctly closed) Just to sort out terminology issue: there were different naming conventions in those bugs so to make it straight, when referring to crash I mean the crash that happened before ObjectNotFoundException. ObjectNotFoundException is not a crash itself, it's just inability to start the workspace. Since we can see .snap file, we can assume that previous Eclipse launch session was not correctly finalized. Knowing that, the state of workspace is the state of workspace at some point in time just before the crash. I have seen two broken workspaces and in both cases the workspace was not consistent. To be precise, the state of master table was not consistent. Looking at the workspace uploaded by Andy in comment 46, you can see that master table consists of three chunks with the following values (order preserved, unrelated entries skipped): #Tue Mar 01 10:27:54 PST 2011 /.tree=26 #Tue Mar 01 10:27:55 PST 2011 /.tree=26 #Tue Mar 01 22:55:04 PST 2011 /.tree=25 In .root folder you can see only "26.tree" file. Master table is a java.util.Properties instance which means that latest key=value entry overrides previous entries. In this case we would end up with /.tree=25 as the current one. When starting the workspace, Eclipse tries to use .snap to update .tree file pointed by master table. In this case it cannot find 25.tree so tree update is not successful and we get ObjectNotFoundException. Having this information we can assume that if the crash happened before 22:55:04, the master table would have been in sync with .tree file. Since we cannot prevent from externally triggered crash (killall, power down, etc.), we have to make sure that the state of workspace is consistent at any point in time. It looks that currently it is not. This confirms that we have a hole somewhere as mentioned by Martin in comment 26. At the moment I do not know the steps that lead to this situation but there are at least two issues that bother me: 1. In SaveManager#restoreMasterTable we are creating new master table. This method is accessible in catch clause from different threads with non-conflicting project rules. I think there should be only one instance of master table. It would be better to so something like this: if (masterTable == null) masterTable = new Properties(); else masterTable.clear(); This would also prevent from using old master table values if we call #getMasterTable. 2. It is possible to call SaveManager#save(FULL_SAVE, project, monitor) and in this case we would have two threads modifying master table - incrementing sequence number for root and creating new tree for root. We could prevent from that by changing the rule to workspace root if FULL_SAVE was requested. I will try to find the real steps that can introduce such inconsistencies in master table. About the workaround: deleting .snap means we do not need to update the tree, and since there is no tree file pointed by master table, it starts with clean tree. Deleting is not a proper workaround. The only proper manual workaround is to change 25 to 26 in latest entry in file: workspace\.metadata\.plugins\org.eclipse.core.resources\.safetable\org.eclipse.core.resources Using this this workaround we are not losing any information.
In broken workspaces there are always three chunks in master table file. FULL_SAVE creates always new master table file and two new chunks with very close timestamps so the third chunk is most likely saved during SNAPSHOT. In Andy's workspace I found the file workspace\.metadata\.plugins\org.eclipse.core.zip which contains master table file and .snap with modification time matching the timestamp in the last chunk. This implies that just before 22:55:04 there was a snapshot taken that created .snap file and invalidated master table file. At the moment, we know that master table is corrupted by snapshot job (in Andy's case). The remaining question is how it was possible that snapshot job had older entries in master table.
In another broken workspace, master table file has the following entries: #Thu Oct 22 17:18:08 CEST 2009 /.tree=188 #Thu Oct 22 17:18:08 CEST 2009 /.tree=188 #Thu Oct 22 17:20:57 CEST 2009 /.tree=186 There is only one tree file for root - 188.tree. Modification time for 188.tree is 17:18:10 and for .snap it is 17:20:58. It looks that snapshot is the culprit also in this case. In .logs from Andy's workspace there are exceptions logged in the same session when snapshot occurred (according to timestamps) but about 2 hours after the snapshot. It looks like the problem with wrong entries in master table file is not something unusual and after it happens, Eclipse still works "normally". This can imply that master table file is not-in-sync with master table kept in memory because of ugly snapshot. It may happen more often but since each FULL_SAVE recreates master table file, we may not know when we modified master table in the wrong way. We see the problem only when we crash the workspace with not-in-sync master table file. Only then, during next Eclipse startup, master table is reconstructed from the file with wrong values.
Created attachment 192630 [details] Patch v.0.1 This patch solves two problems: 1. Makes it possible to start Eclipse if master table is corrupted. If it happens, a stack trace with message will be logged and Eclipse will use the greatest sequence number for root to load the tree. 2. Prevents from master table corruption in the future by throwing an exception. This way we should not fall into problem 1 if crash occurs. You may apply the patch and try to open Andy's workspace. We still do not have steps to recreate the original scenario, but solving above problems should prevent from that and log exceptions when it happens. Comments are welcome.
I received another workspace from a customer that exhibits this. The problem was most likely introduced due to a crash. We first tried to delete .snap file, which allowed to open the workspace, but project was not listed and some resources(files) were not accessible. Then, we tried the workaround that Szymon suggested in comment #50. This allowed the workspace to be opened, project was restored and source files were opened, but it seems to have triggered a CDT parsing issue that seems to use up entire heap causing a pop up message asking user to exit the workbench. My guess is that this is not a platform/resource issue, but if the fix to this issue is to adjust master table to point to correct tree, then most likely there will need to be a fix made in CDT as well. I am posting here for continuity and to notify few people from CDT community that have subscribed to this bugzilla. Below is the call stack that seems to trigger the issue. I'll file a CDT bug as well. Martin !ENTRY org.eclipse.cdt.ui 4 4 2011-04-07 14:39:32.490 !MESSAGE Error !STACK 0 java.lang.OutOfMemoryError: Java heap space at java.util.ArrayList.ensureCapacity(Unknown Source) at java.util.ArrayList.add(Unknown Source) at org.eclipse.cdt.internal.core.pdom.dom.PDOMFile.getMacros(PDOMFile.java:580) at org.eclipse.cdt.internal.core.index.IndexBasedFileContentProvider.collectFileContent(IndexBasedFileContentProvider.java:174) at org.eclipse.cdt.internal.core.index.IndexBasedFileContentProvider.getContentForInclusion(IndexBasedFileContentProvider.java:125) at org.eclipse.cdt.internal.core.parser.scanner.CPreprocessor$1.checkFile(CPreprocessor.java:103) at org.eclipse.cdt.internal.core.parser.scanner.CPreprocessor$1.checkFile(CPreprocessor.java:1) at org.eclipse.cdt.internal.core.parser.scanner.CPreprocessor.findInclusion(CPreprocessor.java:935) at org.eclipse.cdt.internal.core.parser.scanner.CPreprocessor.executeInclude(CPreprocessor.java:1251) at org.eclipse.cdt.internal.core.parser.scanner.CPreprocessor.executeDirective(CPreprocessor.java:1067) at org.eclipse.cdt.internal.core.parser.scanner.CPreprocessor.internalFetchToken(CPreprocessor.java:726) at org.eclipse.cdt.internal.core.parser.scanner.CPreprocessor.fetchToken(CPreprocessor.java:469) at org.eclipse.cdt.internal.core.parser.scanner.CPreprocessor.nextToken(CPreprocessor.java:563) at org.eclipse.cdt.internal.core.dom.parser.AbstractGNUSourceCodeParser.fetchToken(AbstractGNUSourceCodeParser.java:260) at org.eclipse.cdt.internal.core.dom.parser.AbstractGNUSourceCodeParser.nextToken(AbstractGNUSourceCodeParser.java:284) at org.eclipse.cdt.internal.core.dom.parser.AbstractGNUSourceCodeParser.acceptInactiveCodeBoundary(AbstractGNUSourceCodeParser.java:345) at org.eclipse.cdt.internal.core.dom.parser.AbstractGNUSourceCodeParser.declarationList(AbstractGNUSourceCodeParser.java:1283) at org.eclipse.cdt.internal.core.dom.parser.AbstractGNUSourceCodeParser.parseTranslationUnit(AbstractGNUSourceCodeParser.java:1253) at org.eclipse.cdt.internal.core.dom.parser.AbstractGNUSourceCodeParser.translationUnit(AbstractGNUSourceCodeParser.java:1248) at org.eclipse.cdt.internal.core.dom.parser.AbstractGNUSourceCodeParser.parse(AbstractGNUSourceCodeParser.java:645) at org.eclipse.cdt.core.dom.parser.AbstractCLikeLanguage.getASTTranslationUnit(AbstractCLikeLanguage.java:143) at org.eclipse.cdt.internal.core.model.TranslationUnit.getAST(TranslationUnit.java:806) at org.eclipse.cdt.internal.core.model.TranslationUnit.getAST(TranslationUnit.java:770) at org.eclipse.cdt.internal.core.model.ASTCache$1.run(ASTCache.java:295) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.cdt.internal.core.model.ASTCache.createAST(ASTCache.java:289) at org.eclipse.cdt.internal.core.model.ASTCache.getAST(ASTCache.java:168) at org.eclipse.cdt.internal.core.model.ASTCache.runOnAST(ASTCache.java:215) at org.eclipse.cdt.internal.ui.editor.ASTProvider.runOnAST(ASTProvider.java:344) at org.eclipse.cdt.internal.ui.text.c.hover.CSourceHover$1.run(CSourceHover.java:734) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
(In reply to comment #54) > I received another workspace from a customer that exhibits this. The problem > was most likely introduced due to a crash. We first tried to delete .snap file, > which allowed to open the workspace, but project was not listed and some > resources(files) were not accessible. Then, we tried the workaround that Szymon > suggested in comment #50. This allowed the workspace to be opened, project was > restored and source files were opened, but it seems to have triggered a CDT > parsing issue that seems to use up entire heap causing a pop up message asking > user to exit the workbench. My guess is that this is not a platform/resource > issue, but if the fix to this issue is to adjust master table to point to > correct tree, then most likely there will need to be a fix made in CDT as well. > > I am posting here for continuity and to notify few people from CDT community > that have subscribed to this bugzilla. Below is the call stack that seems to > trigger the issue. I'll file a CDT bug as well. Martin, thanks for the feedback. If you still have this broken workspace, could you check what entries were written in master table file? I am interested in entries similar to those in comment 50 or comment 52 (with timestamps). I assume there is only one tree file for root that matches exactly the biggest number in master table file, right? Was there any network drive involved?
This is what the master table looks like (some properties removed from below for clarity) #Wed Apr 06 17:32:47 CDT 2011 /.tree=6 #Wed Apr 06 17:32:47 CDT 2011 /.tree=6 #Wed Apr 06 17:35:00 CDT 2011 /.tree=5 .root directory only has 6.tree in it. To try the workaround I edited last entry and changed it to 6.
Szymon B, could you comment on the above findings?
Created attachment 193267 [details] Patch v.0.2 As discussed with Szymon B, messages should be put in the code directly.
I like the patch. It adds more tracing and recovers broken workspaces. We still don't know what breaks workspaces, but hopefully extra tracing will help to figure it out.
The fix is in HEAD. I just slightly modified wording.
Created attachment 194146 [details] Part of Patch v.0.2 reverted I had to revert part of the fix to get rid of perf regression, see bug 343815. The reverted part is the sanity check in SaveManager#saveMasterTable.
I'm lowering the severity of the bug, since broken workspaces are now recovered on Eclipse startup. I'm leaving the bug open to investigate the reverted part that caused a perf regression.
I should rather leave the old severity, mark the bug fixed and raise a new one to investigate the SaveManager#saveMasterTable check issue... Done. The new bug is Bug 343977. And thanks Szymon P. for working on it!
*** Bug 345553 has been marked as a duplicate of this bug. ***
(In reply to comment #64) > *** Bug 345553 has been marked as a duplicate of this bug. *** I've just hit this problem with 3.6.2 when moving workspaces between machines. Which release would I need to download to test the fix?
(In reply to comment #65) > I've just hit this problem with 3.6.2 when moving workspaces between machines. > Which release would I need to download to test the fix? You need one of the latest I-builds, e.g. this one: http://download.eclipse.org/eclipse/downloads/drops/I20110510-0800/index.php Are you able to zip your workspace (or just .metadata folder) and attach it to this bug? We could compare it with previous workspaces to see if we can tell something more about the root cause of the problem.
> You need one of the latest I-builds, e.g. this one: > http://download.eclipse.org/eclipse/downloads/drops/I20110510-0800/index.php Just tested this build and the problem still exists. > Are you able to zip your workspace (or just .metadata folder) and attach it to > this bug? We could compare it with previous workspaces to see if we can tell > something more about the root cause of the problem. Zipped metadata (without mylyn) is still 80mb- shall I put it somewhere for download from your side?
(In reply to comment #67) > > You need one of the latest I-builds, e.g. this one: > > http://download.eclipse.org/eclipse/downloads/drops/I20110510-0800/index.php > > Just tested this build and the problem still exists. > > > Are you able to zip your workspace (or just .metadata folder) and attach it to > > this bug? We could compare it with previous workspaces to see if we can tell > > something more about the root cause of the problem. > > Zipped metadata (without mylyn) is still 80mb- shall I put it somewhere for > download from your side? You can make it available via FTP server. Or you can check which folder is the biggest and if it is not relevant you can exclude it from zip. What we need is .metadata/.plugins/org.eclipse.core.resources folder.
> > > You need one of the latest I-builds, e.g. this one: > > > http://download.eclipse.org/eclipse/downloads/drops/I20110510-0800/index.php > > > > Just tested this build and the problem still exists. ... > You can make it available via FTP server. Or you can check which folder is the > biggest and if it is not relevant you can exclude it from zip. What we need is > .metadata/.plugins/org.eclipse.core.resources folder. Szymon, thanks for your help. It's available here, size if 10mb: http://www.cpuidle.de/.metadata.zip If I can help any please let me know.
(In reply to comment #69) > Szymon, thanks for your help. It's available here, size if 10mb: > http://www.cpuidle.de/.metadata.zip > If I can help any please let me know. Andreas, I have reviewed your .metadata and it looks that you see the same exception but the cause is different. In all known cases, exception was caused by wrong entries in master table file. Your master table file is ok, but there is something wrong with your .snap file - its modification date is very old (2009-06-06) and does not match the date of .tree file (2011-03-25). Since the cause is different, I will reopen your original bug 345553 and we will continue the investigation there.
*** Bug 356731 has been marked as a duplicate of this bug. ***
*** Bug 396897 has been marked as a duplicate of this bug. ***
Still present in 4.3.1 My cimcumstances: - I work on a virtual Windows 7 installation - Virtualization through VMware - I stop Ecplise which finished up normally without any crash - I shutdown Windows 7 - Now I upgrade VMware 9 to VMware 10 - In upgrade Vmware-Tools - I start Eclipse - Booom I was able to restart eclipse after deleting .snap but all my projects were gone after this. I did NOT mov my installation to another machin nor did I copy anything to another localisation. This is not fixed or resolved (as the status states).
(In reply to Stefan Lindner from comment #73) > Still present in 4.3.1 > > My cimcumstances: > - I work on a virtual Windows 7 installation > - Virtualization through VMware > - I stop Ecplise which finished up normally without any crash > - I shutdown Windows 7 > - Now I upgrade VMware 9 to VMware 10 > - In upgrade Vmware-Tools > - I start Eclipse > - Booom > > I was able to restart eclipse after deleting .snap but all my projects were > gone after this. > I did NOT mov my installation to another machin nor did I copy anything to > another localisation. > > This is not fixed or resolved (as the status states). If you observe ObjectNotFoundException in 4.3.1, you are probably affected by a different bug because 4.3.1 can recover from bad state in master table automatically. Please open a new bug and attach the affected workspace there. Thanks!
Still happens in a slightly different form in Eclipse 4.4RC4 (bug 437005).
(In reply to Sergey Prigogin from comment #75) > Still happens in a slightly different form in Eclipse 4.4RC4 (bug 437005). I confirm that my Eclipse Luna exited during start-up (after a previous crash). The problem did not went away by simply restarting it or passing the -clean option. However I could resolve it by deleting the .metadata/.plugins/org.eclipse.core.resources/.snap file (unfortunately, I did not keep the file).
happens on eclipse rcp luna sr1 also. stacktrace of .log file: java.lang.NoClassDefFoundError: org/eclipse/core/resources/IContainer at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:136) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603) at org.eclipse.equinox.launcher.Main.run(Main.java:1465) at org.eclipse.equinox.launcher.Main.main(Main.java:1438) Caused by: java.lang.ClassNotFoundException: An error occurred while automatically activating bundle org.eclipse.core.resources (81). at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:116) at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:531) at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:324) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:320) at org.eclipse.osgi.internal.loader.sources.SingleSourcePackage.loadClass(SingleSourcePackage.java:36) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:391) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:345) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:337) at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) ... 14 more Caused by: org.osgi.framework.BundleException: Exception in org.eclipse.core.resources.ResourcesPlugin.start() of bundle org.eclipse.core.resources. at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:792) at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:721) at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:936) at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:319) at org.eclipse.osgi.container.Module.doStart(Module.java:571) at org.eclipse.osgi.container.Module.start(Module.java:439) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:454) at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107) ... 23 more Caused by: org.eclipse.core.internal.dtree.ObjectNotFoundException: Tree element '/bluetooth_test/bin/bluetooth_test/Bluez.class' not found. at org.eclipse.core.internal.dtree.AbstractDataTree.handleNotFound(AbstractDataTree.java:257) at org.eclipse.core.internal.dtree.DeltaDataTree.getData(DeltaDataTree.java:585) at org.eclipse.core.internal.dtree.DataDeltaNode.asBackwardDelta(DataDeltaNode.java:50) at org.eclipse.core.internal.dtree.DataDeltaNode.asBackwardDelta(DataDeltaNode.java:47) at org.eclipse.core.internal.dtree.NoDataDeltaNode.asBackwardDelta(NoDataDeltaNode.java:59) at org.eclipse.core.internal.dtree.NoDataDeltaNode.asBackwardDelta(NoDataDeltaNode.java:59) at org.eclipse.core.internal.dtree.DataDeltaNode.asBackwardDelta(DataDeltaNode.java:47) at org.eclipse.core.internal.dtree.DeltaDataTree.asBackwardDelta(DeltaDataTree.java:88) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:816) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:792) at org.eclipse.core.internal.watson.ElementTree.immutable(ElementTree.java:518) at org.eclipse.core.internal.resources.SaveManager.restore(SaveManager.java:722) at org.eclipse.core.internal.resources.SaveManager.startup(SaveManager.java:1565) at org.eclipse.core.internal.resources.Workspace.startup(Workspace.java:2464) at org.eclipse.core.internal.resources.Workspace.open(Workspace.java:2219) at org.eclipse.core.resources.ResourcesPlugin.start(ResourcesPlugin.java:447) at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:771) at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:764) ... 30 more
(In reply to Michael Mangeng from comment #77) > happens on eclipse rcp luna sr1 also. > stacktrace of .log file: > java.lang.NoClassDefFoundError: org/eclipse/core/resources/IContainer > at This indicates that something went wrong when you upgraded to SR1. I suggest you download a new package from https://www.eclipse.org/downloads/
(In reply to Dani Megert from comment #78) > (In reply to Michael Mangeng from comment #77) > > happens on eclipse rcp luna sr1 also. > > stacktrace of .log file: > > java.lang.NoClassDefFoundError: org/eclipse/core/resources/IContainer > > at > > This indicates that something went wrong when you upgraded to SR1. I suggest > you download a new package from https://www.eclipse.org/downloads/ hmm i don't think so because the real cause is the root cause and not the NoClassDefFoundError. Furthermore NoClassDefFoundError does not mean that the class is not available but that it could not be loaded because of another reason (see root exception). problem must be related to this exception: Caused by: org.eclipse.core.internal.dtree.ObjectNotFoundException: Tree element '/bluetooth_test/bin/bluetooth_test/Bluez.class' not found. at org.eclipse.core.internal.dtree.AbstractDataTree.handleNotFound(AbstractDataTree.java:257) at org.eclipse.core.internal.dtree.DeltaDataTree.getData(DeltaDataTree.java:585) (the mentioned file is there). i also tried removing it and tried removing the .snap file - but this does not help. i had been using luna-sr1 since the first day it was released. after i rebooted my pc and restarted eclipse today, this is what happened. i think something in the metadata of the workspace got scrambled. i switched to a new workspace and now everything is working well again. i kept the old workspace - so i can still investige this issue if somebody has questions.
(In reply to Michael Mangeng from comment #79) > i kept the old workspace - so i can still investige this issue if somebody > has questions. Please open a new bug against Platform/Resources and attach your workspace there. This bug has been fixed long ago so you are probably affected by a different problem that also leads to ObjectNotFoundException.
*** Bug 474728 has been marked as a duplicate of this bug. ***
