Community
Participate
Working Groups
Created attachment 229312 [details] StackOverflowError in CVS history view From time to time I'm getting a StackOverflowError in the CVS history view (see attached stacktrace). I cannot reproduce, but when it happens the only way to resolve it, is to shutdown Eclipse and delete the workbench.xmi (as the stackoverflow appears again after restarting Eclipse).
happened to me as well. When using the CVS history view, eclipse crashed and refused to start again until I deleted the workspace.xmi.
Created attachment 229321 [details] stackoverflow
As several colleagues now also get this on a quite regular basis and it prevents Eclipse from being started again, unless you delete your workspace or know what you have to delete I think this is a major bug. Increase importance
For me it happens every time a pom.xml is currently open in the m2e POM editor and I try to open a CVS history view which is linked with editor and selection. If the history of the currently edited POM is requested the stackoverflow happens and the history view that finally opens is empty. This can be seen in attachment #229321 [details] where finally an SWTError happens. At the time the SWTError happens it can happen that eclipse tells me to close it due to an error and at this time the workspace.xmi will be corrupted. If the history of another file is requested while the POM editor is open the stackoverflow happens but there is no SWTError and the history view is displayed with content. In both cases it takes a lot of time to get the history view shown. If the history view is not linked with editor and selection the issue does not happen.
I can reassure this is a critical issue in v4.2.2. Several colleagues are working with a fresh v4.2.2 install, open (mostly a pom.xml) file and while switching to the history view eclipse crashes with the same log entry as attachment "stackoverflow". Because of this bug we are using v3.7 now, I would call it critical for our environment.
Same problem for me here. Small hint to recover the xmi file : Even if it's producing a stack overflow when opening a SR2, it's not when i open a SR1. Thus once i have my workbench opened in SR1, i get ride of all history tabs in all my views and exit SR1. Then SR2 start with the modified xmi file.
I can confirm that all of these are valid. When the the o.e.t.internal.ui.history.GenericHistoryView receives a selection changed event, where there is an available resource, it enters into an infinite recursive re-entrant loop. In the attached log I put line breaks at every call to: org.eclipse.team.internal.ui.history.GenericHistoryView$2.selectionChanged(GenericHistoryView.java:364) When the stack overflow happens, this causes the workbench part (PageBookView) to become corrupted. Which will then cause EMF exceptions in the o.e.e4.u.internal.workbench.ResourceHandler. These exceptions prevent the loading of the previous workbench state. In addition, @Dani when you updated the GenericHistoryView in August, the changes where not picked up by the 4.2.2 release even though the build identifier is: org.eclipse.team.ui_3.6.201.v20130125-135424. I have attached the source for GHV from the 4.2.2 distro. The attached source is equivalent to this git commit[1]. Thus there are multiple issues at work here. Where we need to go from here: 1) Determine if the issue persists with the changes from Dani. I have not tested to see if I am able to recreate the SOE with the latest code (the code that should have been in 4.2.2). I will try to do that later this coming week, but I am in the middle of a release. 2) Figure out why Dani's changes (and many others) were not picked up by the 4.2.2 build 3) Look at the ResourceHandler and determine if some kind of prevalidation should happen to circumvent/delete corrupted application elements in the workbench.e4xmi. This will allow the workbench to restore all "valid" persisted states. It might actually be better to look at our save handler to prevent corrupted application elements from being persisted in the first place. JD [1] http://git.eclipse.org/c/platform/eclipse.platform.team.git/tree/bundles/org.eclipse.team.ui/src/org/eclipse/team/internal/ui/history/GenericHistoryView.java?id=8bd7229015f8e34a5c3e23ca9b86504023141b51
Created attachment 232133 [details] Workbench Log
Created attachment 232134 [details] Workbench Log
Created attachment 232135 [details] GenericHistoryView source
For reference: Item #2 bug 410272 Item #3 bug 410273
(In reply to comment #7) > I can confirm that all of these are valid. Can you reproduce it with 4.3 RC4? Do you have steps?
*** Bug 408099 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > In addition, @Dani when you updated the GenericHistoryView in August, the > changes where not picked up by the 4.2.2 release even though the build > identifier is: > org.eclipse.team.ui_3.6.201.v20130125-135424. Those changes were made in 'master' for Kepler (4.3). They did not fix a critical bug and hence it is expected that they neither appear in 4.2.1 nor 4.2.2. The identifier is 3.6.201 due to other changes made in team.ui for 4.2.2.
*** Bug 410898 has been marked as a duplicate of this bug. ***
I tried hard to reproduce this using our Kepler release candidate: http://download.eclipse.org/eclipse/downloads/drops4/S-4.3RC4-201306052000/ but no "luck". Please reopen, if you can provide more detailed steps using 4.3 RC4 or newer. The problem with the broken workbench.xmi is still tracked by bug 410273. As you probably know, the source for the "no more handled" can also be caused by some completely different area, and at some point you just run out of handles, e.g. in the History view.
(In reply to comment #16) > As you probably know, the source for the "no more handled" can also be > caused by some completely different area, and at some point you just run out > of handles, e.g. in the History view. Please ignore that part - it was meant for a different bug report.
*** Bug 412266 has been marked as a duplicate of this bug. ***
Please reopen this bug. Problem reproduced everytime with Eclipse Kepler Release. 1) Create a new Workspace 2) Create a new "Dynamic Web project" 3) Add a new CVS repository 4) Create a new web.xml file in WEB-INF folder 5) Team Share Project... 6) Open "History" view and enable "Link with Editor and Selection" 7) Open web.xml -> Unhandled event loop exception java.lang.StackOverflowError I can't restart Eclipse until workbench.xmi is deleted. CVS History view allways crash if the first opened file is an XML. If another file was opened before to init the History view, then the XML History is OK. But if I close Eclipse with an XML file opened in the editor, then Eclipse can not restart until deleting workbench.xmi
(In reply to comment #19) Thanks a lot for the steps! I can now reproduce the problem. It only surfaces with WTP editors which have a structured selection.
*** Bug 407989 has been marked as a duplicate of this bug. ***
Fixed in 'master' with http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=f743d2de7592e078b2fd7b49dc80a884c6106536 Gosia, please review the fix for inclusion in 4.3.1.
This code: + if (!isLinkingEnabled() || !checkIfPageIsVisible()) { + return; + } + + showLastSelectedElement(); could be improved to: if ( isLinkingEnabled() && checkIfPageIsVisible() ) { showLastSelectedElement(); } IHMO, this is more readable by avoiding negation.
(In reply to comment #23) > This code: > > + if (!isLinkingEnabled() || !checkIfPageIsVisible()) { > + return; > + } > + > + showLastSelectedElement(); > > could be improved to: > > if ( isLinkingEnabled() && checkIfPageIsVisible() ) { > showLastSelectedElement(); > } > > IHMO, this is more readable by avoiding negation. Sure. Feel free to file a separate bug report for this, as it is unrelated to this one.
As you touched this part of code about 20 minutes ago it would be a simple change for you. I do not see any need to file an extra bug for this simple refactoring. I was just curious and looked at the git diff link you provided and it caught my eye. Maybe the refactoring is not correct for some reason...
*** Bug 412583 has been marked as a duplicate of this bug. ***
*** Bug 357669 has been marked as a duplicate of this bug. ***
*** Bug 392494 has been marked as a duplicate of this bug. ***
*** Bug 405262 has been marked as a duplicate of this bug. ***
(In reply to comment #22) > Fixed in 'master' with > http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/ > ?id=f743d2de7592e078b2fd7b49dc80a884c6106536 > > > Gosia, please review the fix for inclusion in 4.3.1. I'm OK with including this fix in 4.3.1, but shouldn't isUpdatingSelection be volatile?
(In reply to comment #30) > I'm OK with including this fix in 4.3.1, but shouldn't isUpdatingSelection > be volatile? No, this is not needed in this case because the selection change event is always sent by the same thread. Fixed with http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=f8de70ec6154b04986c8249dea13c573a722c669
still here in Eclipse Java EE IDE for Web Developers. Version: Kepler Release Build id: 20130614-0229
I also confirm that this is still present in Eclipse Java EE IDE for Web Developers. Version: Kepler Release Build id: 20130614-0229
Resolved in Kepler Service Release 1 Build id: 20130919-0819
(In reply to Miroslav Zaťko from comment #32) > still here in > Eclipse Java EE IDE for Web Developers. > Version: Kepler Release > Build id: 20130614-0229 (In reply to David I from comment #33) > I also confirm that this is still present in > > Eclipse Java EE IDE for Web Developers. > Version: Kepler Release > Build id: 20130614-0229 You can take a look at the target milestone (in this case 4.3.1 aka Kepler SR1) to see when a bug got fixed. If that is newer than your build, then it is obvious that your build does not contain the fix.
It looks like SR1 fixed the issue.
Backported to 4.2.2+ with http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=40d0ba0794763196261101dffb294e948cfa0ea8
