Community
Participate
Working Groups
3.3 RC1 I have back linking enabled and the History view is a fast view. Sometimes it fails to load the revision for the active editor. Reselecting or reopening this editor doesn't help. This happens at least once a day but I could not yet norrow this down to a concrete scenario. Nothing in .log.
Created attachment 68097 [details] History view in corrupt state
I've seen this too but I've never been able to track it down.
Daniel, what about the CVS console? Have you noticed anything unusual there?
>Daniel, what about the CVS console? I'm not using the Console. I'm pretty sure it has to do with the fact that it is a fast view.
> I'm pretty sure it has to do with the fact that it is a fast view. Nope, I also see this with the History view on top of a normal view stack, linking enabled.
I think I've managed to reproduce it (on I20070625-1500). Here is how my stack trace looks like: java.lang.ArrayIndexOutOfBoundsException: 0 at org.eclipse.team.internal.ccvs.ui.CVSHistoryTableProvider.adaptToFileRevision(CVSHistoryTableProvider.java:439) at org.eclipse.team.internal.ccvs.ui.CVSHistoryTableProvider$HistoryLabelProvider.isSingleLine(CVSHistoryTableProvider.java:129) at org.eclipse.team.internal.ccvs.ui.CVSHistoryTableProvider$HistoryLabelProvider.useNativeToolTip(CVSHistoryTableProvider.java:125) at org.eclipse.jface.viewers.ColumnViewerToolTipSupport.shouldCreateToolTip(ColumnViewerToolTipSupport.java:116) at org.eclipse.jface.window.ToolTip.toolTipCreate(ToolTip.java:316) at org.eclipse.jface.window.ToolTip.access$2(ToolTip.java:315) at org.eclipse.jface.window.ToolTip$ToolTipOwnerControlListener.handleEvent(ToolTip.java:580) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3682) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3293) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219) at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176) 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.equinox.launcher.Main.invokeFramework(Main.java:504) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443) at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
>I think I've managed to reproduce it (on I20070625-1500). Here is how my stack >trace looks like: There's no .log entry when this happens to me (otherwise I would have attached it here ;-).
Sorry, it must be a false trail then. But I will investigate it anyway. In the meantime Daniel, if you came across the problem again with some other clues please let me know.
My plan is to find this out today.
Are there scenarios where a TeamException can have n OK status?
I tried to figure it out but no luck so far. Not sure whether this matters: I have single-click enabled and work with three workbench windows.
ping. any update?
It looks like this is a problem with showing the History view for the first time after restarting the workbench. Steps in I20070710-1416: - new workspace - File > Import > CVS > Projects from CVS - paste :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse - check out org.eclipse.core.expressions - in Package Explorer, open org.eclipse.core.expressions/ElementHandler.java - Alt+Shift+W, H => History view quickly shows "No Revision" (bug 183953), and then shows correct history - enable "Link with Editor and Selection" - activate Problems view (thereby hiding History view) - restart workbench - Alt+Shift+W, H => History view stays empty, Refresh restores normal operation
Nope, I also see it during the day.
Ping. This happens several times a day and makes working with the History view a pain.
Daniel, I managed to reproduce it few times while working on other bugs, at least I hope it was it. Unfortunately, I couldn't find any trace of an error. I will spend this day focusing more on this particular bug and looking for some clues.
(In reply to comment #16) You could start with comment 13. Although it may not be exactly Dani's problem, it maybe has the same underlying cause.
Correct me if I'm wrong, but for me using Show In > History (Alt+Shift+W, H) on both an entry in the Package Explorer and an opened class result in empty History View (Refresh fills the view). I don't need to restart workbench to observe that, but the History View must be set as a fast view.
>Show In > History (Alt+Shift+W, H) I don't care about this scenario ;-) I have it as fast view with enabled linking.
Dani, can you confirm that what you described happens only when fetching revision history for a Java file (Compilation Unit)?
I'll report back when I see it again but as far as I can remember I also had it on normal resource (i.e. in text editor). Maybe that's important: normally it happens when the focus is on the editor.
I just had it with a plugin.xml editor: - History linking enabled - History view buried below other views - opened plugin.xml - switched to source tab - clicked History view tab
I've just bumped into a case which looks identical to the one from the attachment ("No Remote Revisions" for a shared file). This is what I've got in my Error Log: ----------------------------------- eclipse.buildId=I20070808-1800 java.version=1.5.0_10 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=pl_PL Framework arguments: -product org.eclipse.sdk.ide -pdelaunch Command-line arguments: -product org.eclipse.sdk.ide -data C:\workspace\runtime-EclipseApplication -dev file:C:/workspace/eclipse/team/dev.eclipse.org_HEAD/.metadata/.plugins/org.eclipse.pde.core/Eclipse Application/dev.properties -pdelaunch -os win32 -ws win32 -arch x86 Error Thu Aug 09 17:30:03 CEST 2007 Could not connect to :pserver:dev.eclipse.org:/cvsroot/eclipse: Cannot locate host: dev.eclipse.org org.eclipse.team.internal.ccvs.core.connection.CVSCommunicationException: Could not connect to :pserver:dev.eclipse.org:/cvsroot/eclipse: Cannot locate host: dev.eclipse.org at org.eclipse.team.internal.ccvs.core.connection.Connection.open(Connection.java:134) at org.eclipse.team.internal.ccvs.core.connection.CVSRepositoryLocation.createConnection(CVSRepositoryLocation.java:547) at org.eclipse.team.internal.ccvs.core.connection.CVSRepositoryLocation.openConnection(CVSRepositoryLocation.java:791) at org.eclipse.team.internal.ccvs.core.client.Session.open(Session.java:159) at org.eclipse.team.internal.ccvs.core.resources.RemoteFile.getLogEntries(RemoteFile.java:279) at org.eclipse.team.internal.ccvs.core.resources.EclipseFile.getLogEntries(EclipseFile.java:295) at org.eclipse.team.internal.ccvs.core.filehistory.CVSFileHistory.refresh(CVSFileHistory.java:99) at org.eclipse.team.internal.ccvs.ui.CVSHistoryPage$RefreshCVSFileHistory.run(CVSHistoryPage.java:1319) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) org.eclipse.team.internal.ccvs.core.connection.CVSCommunicationException[-29]: java.net.UnknownHostException: dev.eclipse.org at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at org.eclipse.team.internal.ccvs.core.util.ResponsiveSocketFactory.internalCreateSocket(ResponsiveSocketFactory.java:137) at org.eclipse.team.internal.ccvs.core.util.ResponsiveSocketFactory$1.run(ResponsiveSocketFactory.java:63) at java.lang.Thread.run(Unknown Source) ----------------------------------- Investigation in progress...
Note that I never get an .log entry when it happens to me.
I remember about that. I'm just informing you about any signs of an abnormal behavior I find while looking for the one of yours. It looks like the History view can throw an exception in many flavors.
When it happens I can go and open the context menu (in the blank list area). When I then select e.g. 'Open', it opens revisions from the previous input even though the new input name is already shown (as in the attached image).
I'm not sure why I changed the priority to P2 last year. I'm lowering the priority to P3.
Mass update - removing 3.4 target. This was one of the bugs marked for investigation (and potential fixing) in 3.4 but we ran out of time. Please ping on the bug if fixing it would be really important for 3.4, and does not require API changes or feature work.
This is a major pain for me and happens every day. Please fix for 3.4. I can help if you tell where/what to debug.
Created attachment 99924 [details] Fix v01
The issue can be easily reproduced with the following steps: 1) Have some shared projects in the package explorer or navigator 2) Open the history view and make it not visible by selecting the problems view or another tab in the page 3) Select a shared file in the explorer and press Alt+Shift+W H to open the history Try couple times for different files, if didn't work from the first time round.
Created attachment 99931 [details] Fix v02 This version is more tricky. I like it more however it is more invasive in the logic of jobs. I performed some manual tests and both work fine.
(In reply to comment #32) > Created an attachment (id=99931) [details] > Fix v02 > > This version is more tricky. I like it more however it is more invasive in the > logic of jobs. > > I performed some manual tests and both work fine. I would go with this one, it doesn't cancel a refresh job if it fetches revisions for the same input. This is more efficient since we don't have to start a new job which does exactly the same every time. However, as Szymon said, this change will need to be double check before releasing. It may introduce some side effects.
The second patch released to HEAD.
I was so happy to see this fixed, but unfortunately still same issue here using I20080513-2000.
The only reproducible steps that we have are those from the comment #13. And this case is fixed. I'm trying to find another steps that cause the same problem, but with no luck so far.
I have split the issue into two. This one I leave for the issue described by Markus in the comment 13 and by me in comment 31. Bug 232119 is for further investigation. Any new details are welcome, since I can't reproduce the issue now with any steps. But please continue in bug 232119.
Thanks for hijacking my bug. This should be done the other way around as the issue I reported in comment 0 is still there and hence this bug as originally reported not fixed. You can't assume that people read through all the comments. They will read the initial description.
I've just had this again with I20080513-2000. I opened a file that was in sync with HEAD, navigated around in it, and then clicked the History view tab. The History view was hidden behind another view (not as fast view), and I think this was the first time I opened the History view after restarting the workbench.
Created attachment 100444 [details] org.eclipse.team.cvs.ui_3.3.100.I20080514.jar
Created attachment 100445 [details] org.eclipse.team.ui_3.4.0.I20080513.jar
Created attachment 100446 [details] .options
I hope to fix in for 3.4. However it won't make it for RC1.
OK, got it again. Here are the corresponding debug entries: 29:00.300: GenericHistoryView#showHistoryPageFor, the object to show is: L/org.eclipse.debug.ui/plugin.xml 29:00.300: GenericHistoryView#showHistoryPageFor, the page to show the history is: org.eclipse.team.internal.ccvs.ui.CVSHistoryPage@c74ff9 29:00.300: CVSHistoryPage#inputSet, needRefresh = true 29:00.300: CVSHistoryPage#inputSet, cancel the old job 29:00.316: CVSHistoryPage#refreshHistory, about to schedule RefreshCVSFileHistoryJob 29:00.363: GenericHistoryView#showHistoryPageFor, the object to show is: /org.eclipse.debug.ui/plugin.xml 29:00.378: CVSHistoryPage#refreshHistory, about to schedule RefreshCVSFileHistoryJob 29:00.378: RefreshCVSFileHistory#run finished, status: Status OK: org.eclipse.core.runtime code=0 OK null If I compare it to a working scenario, it looks as if two RefreshCVSFileHistoryJob jobs are started instead of just one. Maybe it is just coincidence but it appear to me that with writing out the debug info, the problem appears less frequently.
Created attachment 101008 [details] Complete debug output
Got it again: 2:15.682: GenericHistoryView#showHistoryPageFor, the object to show is: L/org.eclipse.jdt.ui/core extension/org/eclipse/jdt/internal/corext/template/java/CodeTe mplateContextType.java 2:15.682: GenericHistoryView#showHistoryPageFor, the page to show the history is: org.eclipse.team.internal.ccvs.ui.CVSHistoryPage@86ecba 2:15.682: CVSHistoryPage#inputSet, needRefresh = true 2:15.682: CVSHistoryPage#inputSet, cancel the old job 2:15.682: CVSHistoryPage#refreshHistory, about to schedule RefreshCVSFileHistoryJob 2:15.745: GenericHistoryView#showHistoryPageFor, the object to show is: F/org.eclipse.jdt.ui/core extension/org/eclipse/jdt/internal/corext/template/java 2:15.745: CVSHistoryPage#refreshHistory, about to schedule RefreshCVSFileHistoryJob 2:15.745: RefreshCVSFileHistory#run finished, status: Status OK: org.eclipse.core.runtime code=0 OK null
Created attachment 101954 [details] Patch v20080526a
Created attachment 101959 [details] Modified plug-in for RC2
Created attachment 101967 [details] Patch v20080526b
Created attachment 101969 [details] Modified team.cvs.ui plug-in for RC2
Created attachment 101970 [details] Modified team.ui plug-in for RC2
https://bugs.eclipse.org/bugs/attachment.cgi?id=101970 doesn't fix the problem. I got it again (see upcoming trace and screen shots).
Created attachment 101986 [details] debug trace info
Created attachment 101987 [details] Picture 1
Created attachment 101988 [details] Picture 2
Unfortunately I'm not able to fix it for 3.4. Moving to 3.4.1.
After a short discussion with Daniel, we agreed that this is not critical for 3.4.1. The main problem is lack of reproducible steps and inability to reproduce it locally on my machines. I hope that adding more tracing will help.
Setting milestone to M7.
Nice try ;-)
I meant setting targer to M6 :)
Setting target milestone to M7.
Started to look a bit closer. Though not having steps to reproduce yet I now know why it is failing sometimes: In cases where the CVS revisions are not filled as expected, CVSHistoryPage.RefreshCVSFileHistory.refreshFlags is set to 1 instead of 3. There are two possible code paths that lead to this: CVSHistoryPage.setFocus() CVSHistoryPage.HistoryResourceListener.resourceChanged(...).new Runnable() {...}.run() The call to CVSHistoryPage.RefreshCVSFileHistory.setRefreshFlags(int) should be protected so that it doesn't modify the field while others are needed/accessing it. Less risky than synchronizing the code might be to cache the state of refreshFlags in the first line of CVSHistoryPage.RefreshCVSFileHistory.run(IProgressMonitor). Other issues (though most like not the cause for this bug here) are that GenericHistoryView.lastSelectedElement is not always set when GenericHistoryView.editorActivated(IEditorPart) is called and that editorActivated(IEditorPart) is called twice when the fast History view becomes active.
Created attachment 131758 [details] Improvement This will reduce the window of a potential conflict (and hopefully fix my main problem) but a 100% correct fix would ensure that all data that can be set from outside is cached when running the job.
(In reply to comment #63) > Created an attachment (id=131758) [details] > Improvement > <text deleted/> Looks reasonable. That is if I cause the illegal state to occur by placing extra code, the fix corrects the problem. However I didn't come with steps that allow to the illegal state to surface by itself, even with breakpoints help. Bug 272510 has been opened to rewrite the way RefreshCVSFileHistory job works. It's targeted for 3.6 though.
Released to HEAD. Marking FIXED. Phew!
I still see it from time to time but it's better. The real solution is really to fix bug 272510.
(In reply to comment #66) > I still see it from time to time but it's better. The real solution is really > to fix bug 272510. See bug 294042.
