Community
Participate
Working Groups
This is a problem I've experienced a few times, and it's likely user error, but maybe there is something that can be done by Mylyn to improve things. Often when changing tasks, I create a patch for the work I'm doing, attach it to the bug report, replace with latest from head, and work on something else. Occasionally, when I reload the patch, I find that some files (or changes) are not included. As you can imagine, this is very frustrating. Now, I can't guarantee that I always activated my task as soon as I started working on it. I'm pretty good, but sometimes I forget and this is likely the cause of the problem. Also, I notice this happens after I refactor. Again, maybe I didn't activate my task (I can't be sure), but I'm 75% sure I did :-). In any event, I assume Mylyn is trying to correlate change sets with your context. Is this correct? If so, can this be disabled?
Ian, can you provide steps how you actually create the patches? Mylyn merely sets the default change set in the Eclipse's team framework but does not little to manage the files associated with the change set. Also note that the synchronize view doesn't always properly update so it may not always show (and include) all outgoing changes in your workspace: http://wiki.eclipse.org/Mylyn_FAQ#My_change_set_is_missing_or_doesn.E2.80.99t_contain_elements_it_should._Help.21
(In reply to comment #1) > Ian, can you provide steps how you actually create the patches? Mylyn merely > sets the default change set in the Eclipse's team framework but does not little > to manage the files associated with the change set. > Hi Steffen, I often create patches in one of two ways. I either select the single project and create patch -> to clipboard, then I go to the bug report and attach what's on my clipboard. or I synchronize with, go through the synchronize view (exclude from view what I don't want), select ALL, create patch -> to clipboard, goto the bug report, attach patch. It could be a side effect of the problem in the synchronize view, I'm not sure. (Is the synchronize view problem a Mylyn problem, or something from team?). Since I don't have accurate reproduceable steps, I'm not really expecting a resolution. This could be a bug in Team, a problem with Mylyn, the problem you pointed out with the synchronize view, or something else all together. I just wanted to open this to see if others have noticed problems. If I click on a project and synchronize with repository, and mylyn doesn't apply a context filter, then I doubt this is a Mylyn issue. Although I only notice this when I'm using Mylyn (but that is about 75% of the time). Thanks for responding Steffen.
Does the Create Patch dialog list all files in the Changes section and are all files selected? I have noticed that occasionally not all check boxes are selected causing files to get omitted from the patch.
(In reply to comment #3) > Does the Create Patch dialog list all files in the Changes section and are all > files selected? I have noticed that occasionally not all check boxes are > selected causing files to get omitted from the patch. I have noticed this, and this might be part of the problem. Whenever I notice this, I hit "select all", but this requires me to notice this. To be honest, I was assuming that Mylyn removes things from this list based on my current context. Is this true? If not, I wonder why the team plugin would remove elements (unless I explicitly hid them from view in the synchronize view).
I am not aware that Mylyn affects the list or selection but I could imagine that the change set management could affect it. Let me know if you find any reproducable steps and I'll watch, too, if I can figure out a pattern when the selection is different.
Created attachment 154191 [details] screen shot or create patch dialog
I ran into this same problem that is visible in the screenshot twice today. I had a task active, right clicked on a CVS change set in the Synchronize view and selected Create Patch. The patch dialog came up but none of folders displayed in Changes was selected. When I cancelled out of the dialog and followed the same steps again it worked. I tried creating patches a couple of times and noticed the following pattern: If I select a different change set by left clicking in the Synchronize view first and then right click on a another change set to create the patch in 1 out of 3 tries not everything is selected. There seems to be a slight delay between opening the dialog, population of the Changes section and selection of the items. It seems that there could be a race condition that sometimes causes the selection to be incomplete but I haven't been able to find steps to always reproduce this. I also this happening once without a task active but with the change set that I was trying to create a patch from set as the default. I am moving this to CVS in the hope of getting input where to start looking to track this bug down?
This sounds similar to bug 201714. I haven't seen it myself but I will start to look more carefully on what's happening when creating a patch in the Sync view.
I had the problem that patches created from the Synchronize view are corrupt if no task is active at that time. I was already suspicious because in the patch wizard not all the changed files were *selected*. But worse is that even after manually selecting them all they *were silently not included* in the patch. Does that sound like something that could be related with Mylyn? My Eclipse version is: Eclipse SDK Version: 3.6.0 Build id: I20100312-1448
Another very dangerous issue is that I can not commit single (or multiple selected) files anymore! I may click on one file in the Synchronize view and choose "Commit" in the popup menu. But the following dialog lists all files of the changeset and will commit them if I don't realize that and stop it. This happened twice to me and left my repository in an inconsistent state that was hard to fix. Maybe it's related? Since all these issues can lead to severe data corruption I'd like to raise the bugzilla severity at least to "Critical". Please let me know if you need additional infos...
(In reply to comment #10) > Another very dangerous issue is that I can not commit single (or multiple > selected) files anymore! I tried to reproduce it using I20100406-1034 with no success. Please open a separate report if you have detailed steps.
*** Bug 314682 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > I tried to reproduce it using I20100406-1034 with no success. Please open a > separate report if you have detailed steps. Bug 314682 has steps to reproduce (self-contained without Mylyn).
(In reply to comment #13) > Bug 314682 has steps to reproduce (self-contained without Mylyn). I tried those steps but failed to reproduce the issue. Markus does it happen each time you follow the steps? The factor that makes it so hard to reproduce is a self-scheduling event handler job, see bug 201714, comment 12. On that bug we admitted that it was not a complete fix, so I guess it's about time to improve the way events are queued and handled.
(In reply to comment #14) > > Bug 314682 has steps to reproduce (self-contained without Mylyn). > > I tried those steps but failed to reproduce the issue. Markus does it happen > each time you follow the steps? It happened consistently when I filed the bug. I tried it again with I20100713-0800, but now it looked a bit different. To reproduce, "massage" the workspace a bit so that it feels at home at the new location: - refresh the workspace (make sure nothing is selected in the Package Explorer and then choose File > Refresh) - switch the Synchronize view to "Incoming Mode" and back to "Outgoing Mode" - restart the workbench After that, I could reproduce again. When I open the Create Patch wizard, I often see exceptions like this in the log: !ENTRY org.eclipse.ui 4 0 2010-07-14 14:46:06.264 !MESSAGE Unhandled event loop exception !STACK 0 org.eclipse.swt.SWTException: Failed to execute runnable (org.eclipse.swt.SWTException: Widget is disposed) at org.eclipse.swt.SWT.error(SWT.java:4083) at org.eclipse.swt.SWT.error(SWT.java:3998) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:137) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4041) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3660) at org.eclipse.jface.window.Window.runEventLoop(Window.java:825) at org.eclipse.jface.window.Window.open(Window.java:801) at org.eclipse.team.internal.ccvs.ui.wizards.GenerateDiffFileWizard.run(GenerateDiffFileWizard.java:80) at org.eclipse.team.internal.ccvs.ui.subscriber.CreatePatchAction.runOperation(CreatePatchAction.java:40) at org.eclipse.team.ui.synchronize.SynchronizeModelAction.run(SynchronizeModelAction.java:96) at org.eclipse.ui.actions.BaseSelectionListenerAction.runWithEvent(BaseSelectionListenerAction.java:168) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4066) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3657) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2629) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2593) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2427) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:670) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:663) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574) at org.eclipse.equinox.launcher.Main.run(Main.java:1407) Caused by: org.eclipse.swt.SWTException: Widget is disposed at org.eclipse.swt.SWT.error(SWT.java:4083) at org.eclipse.swt.SWT.error(SWT.java:3998) at org.eclipse.swt.SWT.error(SWT.java:3969) at org.eclipse.swt.widgets.Widget.error(Widget.java:468) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:340) at org.eclipse.swt.widgets.Widget.getData(Widget.java:525) at org.eclipse.jface.viewers.AbstractTreeViewer.updateChildren(AbstractTreeViewer.java:2623) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefreshStruct(AbstractTreeViewer.java:1867) at org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(TreeViewer.java:721) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1842) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1799) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1785) at org.eclipse.jface.viewers.StructuredViewer$7.run(StructuredViewer.java:1487) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1422) at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:403) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1383) at org.eclipse.jface.viewers.CheckboxTreeViewer.preservingSelection(CheckboxTreeViewer.java:416) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1485) at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:537) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1444) at org.eclipse.team.internal.ui.synchronize.AbstractSynchronizeModelProvider.refreshModelRoot(AbstractSynchronizeModelProvider.java:348) at org.eclipse.team.internal.ui.synchronize.AbstractSynchronizeModelProvider.access$0(AbstractSynchronizeModelProvider.java:341) at org.eclipse.team.internal.ui.synchronize.AbstractSynchronizeModelProvider$2.run(AbstractSynchronizeModelProvider.java:334) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.team.internal.ui.Utils$5.run(Utils.java:857) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134) ... 35 more
Please make sure this gets fixed for 3.7. I had a few incomplete patches recently, and I'm pretty sure I'm not the only one.
I've got the same issue many times myself. Apparently, this does not happen if we create the patch right from package explorer. (right click>team>create patch). Only creating patch from Team Synchronisation view seems to be unreliable. (which is weird)
In case the "org.eclipse.swt.SWTException: Widget is disposed" is relevant to this issue, this could be part of a fundamental problem with disposing and perhaps concurrency: in about every other session where I use the compare editor in the synchronize perspective I get some combination of - "Widget is disposed" - "Graphic is disposed" - NPE in DocumentMerger.doDiff - "Ignored attempt to add saveable that was already registered" - NPE in JavaReconciler.uninstall - background jobs recomputing diffs although all compare editors have been closed And yes, I have to manually select some of my outgoing changes when creating patches, too. This could well be six individual bugs, mostly related to the compare editor, but seeing the stack trace in comment 15 I start to hope that there's a common theme so that several of those could be fixed with a single bullet. Should I attach some of my stacktraces?
Gosia, could you please take a look at this and see if you're able to reproduce?
Ping?
One thing (that may or may not be relevant). I often create my patches from the synchronize view. Sometimes I'll select the projects (or occasionally) the files, right-click and select 'create patch'. It appears that when I don't select things it works. When I do select things it sometimes fails. I'm not sure if that's any help ;).
I managed to reproduce it with steps from Bug 314682. It only happens when you select files and before it does I always see blinking in the patch window. Usually not only some changes are not selected, but as well there are projects missing in the view. And I get errors from comment #14 as well.
(In reply to comment #22) > I managed to reproduce it with steps from Bug 314682. It only happens when you > select files and before it does I always see blinking in the patch window. > Usually not only some changes are not selected, but as well there are projects > missing in the view. And I get errors from comment #14 as well. Gosia this is the most important bug on your M6 list. I would like to see it fixed in M6. Knowing that this is non-trivial issue it may be also early M7. Please keep updating the bug so interested people know where we are with the fix.
Like Tomasz in comment #8 I assumed that this is bug 201714 that wasn't fixed totally, but when I dug dipper into it I came to conclusion that we may be confusing two different problems. bug 201714 was a timing issue that still may be reproduced by creating a breakpoint somewhere in the code updating the tree in create patch wizard. It does not cause the tree content to be inconsistent with the selection and after clicking "Select All" all the unchecked nodes are selected. It does not throw any errors on the console. I didn't manage to reproduce it without debugger so I suppose the fix from bug 201714 is sufficient. When I followed steps from Bug 314682 I managed to similar symptoms that differ in details: 1. I get the same stack trace that Markus did in comment #15. 2. "Select All" button does not select the missing selection 3. The unselected nodes in tree are duplicated, the duplicates of unselected nodes are selected 4. Often some of the selected projects are not listed in a tree, although they do contain changes Based on this I assume everyone who commented on this bug suffer from a different issue than bug 201714.
Created attachment 191767 [details] mylyn/context/zip
Gosia, have a look at org.eclipse.jface.viewers.AbstractTreeViewer.updateChildren(Widget, Object, Object[], boolean), especially line 2633 (1.151) where copying items array takes place.
Created attachment 191828 [details] Fix of disposing tree elements Indeed Tomasz was right. AbstractTreeViewer.updateChildren we are disposing surplus elements. First we are counting a maximum number of items to be disposed and then we iterate though elements until we dispose the calculated value or reach the end of the elements table. I think in the place that Tomasz pointed the idea was to remove the disposed element from the elements table, but with only one System.arraycopy we are removing the element and pushing other elements left. This leaves us with a duplicated element at the end of the table. The last element has been this way multiplicated the number of times this code was executed. If we then disposed the first occurrence of this element and went on to disposing following elements, we are getting a duplicate of element that has already been disposed. This leads to exception that stops the tree to be updated. And this is how we end up with tree with some element duplicated and some missing. I don't know why don't the duplicated elements get selected by "Select All" but I suppose they are in some invalid state. In patch attached I change the array modification so that we get an array 1 item shorter with desired item missing. In this situation the defect occurred only when we collected the content in two parts and displaying the second part required the tree to refreshed. I investigated a few other uses of this viewer, but somehow they never got to dispose last elements in the array.
There's definitely a bug in AbstractTreeViewer.updateChildren(...) and the patch goes into the right direction but we shouldn't copy the array twice. Anyway, we should have the widget disposed discussion in bug 327004 as it contains simple steps to reproduce the problem. Gosia, please take a look at the patch once I've attached it there. Unfortunately Markus mentioned that he got the patch wizard problem many times without the widget disposed error, hence there's probably also another bug in Platform CVS and therefore I'm moving this bug back for further investigation once bug 327004 has been fixed. Hopefully Markus helps to provide steps again.
Gosia, the equals method of the elements probably has a bug.
(In reply to comment #27) > The last element has been this way multiplicated the number of times this code > was executed. If we then disposed the first occurrence of this element and went > on to disposing following elements, we are getting a duplicate of element that > has already been disposed. Could you provide an example of a situation in which this would happen? Something along the lines of: items = [a, b, c, d, e] elementChildren = [a,d,e] When ...something?... the element "e" will be double disposed? I tried using pan-and-paper few different combinations but can't figure out how an element will be disposed of twice. The "items" is a local variable and all subsequent cycles through it are done using "for (int i = 0; i < min; ++i)", not the actual array length. As a result in my pan-and-paper exercise the "items" array does have duplicated items at the end, but I was not able to find how they would be disposed of. (Actually, a JUnit test would be perfect.)
> Could you provide an example of a situation in which this would happen? > > Something along the lines of: > > items = [a, b, c, d, e] > elementChildren = [a,d,e] Oleg, could we keep the viewer discussion in bug bug 327004? Thanks. The problem in this bug is caused by wrong implementation of equals.
(In reply to comment #29) > Gosia, the equals method of the elements probably has a bug. With bug 341259, I've added the org.eclipse.jface/debug/viewers/equalElements debug option for the next N-build (or HEAD of o.e.jface and o.e.ui.workbench). You can enable this on the Tracing tab of your Eclipse runtime launch config. I'll also run with this option enabled in my dev workbench, so if the problem was really caused by TreeViewer elements that are equal, we should find the bad elements soon.
> org.eclipse.jface/debug/viewers/equalElements debug option Note: You also need to enable the general org.eclipse.jface/debug option.
(In reply to comment #29) > Gosia, the equals method of the elements probably has a bug. Indeed elements in items table are duplicated but it seems that it's not equals method but comparator problem. In AbstractTreeViewer#internalAdd, we call createAddedElements that needs to have elements sorted. The sorting is needed because merging existing elements and new elements is optimized and uses the position of previously inserted element as a start point for searching position for current element. If the order is not correct it may result in duplicates. In the tree we display two types of elements ChangeSetDifNodes and UnchangedResourceModelElements. Our comparator (ChangeSetModelSorter) compares correctly ChangeSetDifNodes but comparing other elements delegates to the comparator provided by ChangeSetModelProvider (SynchronizeModelElementSorter). This comparator compares UnchangedResourceModelElements, but the problem is that if it has to compare UnchangedResourceModelElements and ChangeSetModelSorter it gets down to ResourceSorter that always returns 0 for two objects different than Resource. The important information is that UnchangedResourceModelElements embeds a resource and ChangeSetModelSorter doesn't. I can see few propositions how to fix this: 1. ChangeSetModelSorter should always compare by name and shouldn't use SynchronizeModelElementSorter at all (results in projects and change sets are mixed up, sorted by name) 2. ChangeSetModelSorter now checks if elements to compare embed resources, if yes it compares resources, if no it compares the elements. Maybe if one of the elements embeds Resource and the other doesn't we should compare the Resource with the other element? this leaves us with more or less the same order as now, but doesn't leave the comparator 100% safe, for other uses. However it's not used anywhere else.
(In reply to comment #34) > (In reply to comment #29) > > Gosia, the equals method of the elements probably has a bug. > Indeed elements in items table are duplicated but it seems that it's not equals > method but comparator problem. Yes, that might also be a cause. I would assume though that Markus's debug option still finds the problem. Correct?
(In reply to comment #34) Gosia are you able to provide a set of steps or a test case which lead to the potentially faulty behavior of the comparator (or show consequences of using the comparator in it's current shape)? Does tracing added by Markus indicate a problem in those cases?
Created attachment 193043 [details] Modified Markus tracing to indicate the problem (In reply to comment #36) > Does tracing added by Markus indicate a problem in those cases? Markus tracing did not indicated this particular problem because it verified only if there are no duplicates in incoming data. The problem is that after merging incoming data with data already present in the tree there are duplicates in the tree. This attachment shows how the tracing can be changed so that it shows the problem. In general it searches for duplicates in the tree AFTER elements were added.
(In reply to comment #36) > (In reply to comment #34) > > Gosia are you able to provide a set of steps or a test case which lead to the > potentially faulty behavior of the comparator When you have 2 nodes that contain resources a and c, and a node that contains hash set b. For two nodes that contain resources comparator compares resources (a<c) For two nodes, one containing resource one containing hashSet ResourceComparator gets to compare the nodes not the resource+hashSet. Everything that is not a resource for ResourceComparator is equal, so, a=b and b=c. So we get a=b, b=c, but a<c - the comparator is not transitive. > (or show consequences of using the > comparator in it's current shape)? The merge of current and new elements assumes that both elements in tree and elements to add are sorted and optimizes the merge based on that fact. Only searches for duplicates starting from position of last addition. Let's assume that in tree we have "cba" ("sorted" because c=b and b=a) and we want to add "bac" ("sorted" because b=a and a<c). Adding "b": cb^a - we found "b", matched with "b" and pointer stays at "^" Adding "a": cba^ Adding "c" cbac^ - we assume that "bac" is sorted so we don't move the pointer back to find duplicate "c", we assume that there is not duplicate of "c" and we add "c" at the end. The "sorting" is still correct because c=b=a<c This leads to duplicated entries, that caused the root problem.
Created attachment 193051 [details] Fix for the comparator This patch makes the comparator transitive.
(In reply to comment #38) Again, a test case illustrating the issue and proving the patch fixes it would be extremely useful. To be honest, it would also help me to understand what's going on here. Moreover, at this stage, we should be careful with any non-trivial changes. > The merge of current and new elements assumes that both elements in tree and > elements to add are sorted and optimizes the merge based on that fact. Where does the merge take place?
Created attachment 193387 [details] Test for the comparator This test proves that our comparator is not transistent and that it leads to duplicated entries in the tree. Unfortunately the writing the test required lots of hacking to create a tree viewer containing the same comparator as ours but leaving us full control over what is added to the tree and in what order. I would be grateful for some suggestions how to made the test more blackbox.
Created attachment 193562 [details] Test for the comparator v02 The test is fine, but I thought it can be simplified a bit.
Both the fix and updated tests have been applied to HEAD. Available in >=I20110419-0800. Thanks Gosia!
