Community
Participate
Working Groups
I got this when I clicked on a task editor: java.lang.NullPointerException at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:374) at org.eclipse.emf.common.notify.impl.NotificationImpl.dispatch(NotificationImpl.java:1027) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.remove(NotifyingListImpl.java:741) at org.eclipse.emf.common.util.AbstractEList.remove(AbstractEList.java:460) at org.eclipse.mylyn.reviews.spi.edit.remote.AbstractRemoteEditFactoryProvider.close(AbstractRemoteEditFactoryProvider.java:236) at org.eclipse.mylyn.reviews.core.spi.remote.emf.RemoteEmfConsumer.dispose(RemoteEmfConsumer.java:328) at org.eclipse.mylyn.reviews.core.spi.remote.emf.RemoteEmfConsumer.release(RemoteEmfConsumer.java:385) at org.eclipse.mylyn.reviews.core.spi.remote.emf.RemoteEmfConsumer.removeObserver(RemoteEmfConsumer.java:380) at org.eclipse.mylyn.reviews.core.spi.remote.emf.RemoteEmfObserver.dispose(RemoteEmfObserver.java:87) at org.eclipse.mylyn.reviews.ui.spi.editor.ReviewSetContentSection.dispose(ReviewSetContentSection.java:498) at org.eclipse.mylyn.reviews.ui.spi.editor.ReviewSetSection.dispose(ReviewSetSection.java:117) at org.eclipse.ui.forms.ManagedForm.dispose(ManagedForm.java:174) at org.eclipse.ui.forms.editor.FormPage.dispose(FormPage.java:178) at org.eclipse.mylyn.tasks.ui.editors.AbstractTaskEditorPage.dispose(AbstractTaskEditorPage.java:902) at org.eclipse.mylyn.reviews.ui.spi.editor.AbstractReviewTaskEditorPage.dispose(AbstractReviewTaskEditorPage.java:142) at org.eclipse.ui.forms.editor.FormEditor.dispose(FormEditor.java:403) at org.eclipse.ui.forms.editor.SharedHeaderFormEditor.dispose(SharedHeaderFormEditor.java:160) at org.eclipse.mylyn.tasks.ui.editors.TaskEditor.dispose(TaskEditor.java:537) at org.eclipse.ui.internal.WorkbenchPartReference.doDisposePart(WorkbenchPartReference.java:737)
One guess is that this regression was introduced by 2925fa0c6e1f4c9ecf45d65acc3e4cd64f429e78. That's just a guess though. Here's my reasoning: The original design was set up this way for a reason. I don't think CopyOnWriteArrayList is appropriate here. While there are seeming advantages for being able to use an iterator w/o trigerring a CME, in reality it often just masks the issue. (See e.g. http://www.eclipse.org/forums/index.php/t/225952/.) In particular, they aren't great w/ EMF. The observer list should *always have consistent state*, otherwise we're attempting to modify an observer after it is no longer relevant. Specifically, I think what might be happening here is that we're attempting to dispose a consumer when the observer has already been handled.
(In reply to comment #1) > One guess is that this regression was introduced by > 2925fa0c6e1f4c9ecf45d65acc3e4cd64f429e78. That's just a guess though. That makes no sense to me. The bug was reported (July 22) before the change was merged (July 26).
(In reply to comment #2) > (In reply to comment #1) > > One guess is that this regression was introduced by > > 2925fa0c6e1f4c9ecf45d65acc3e4cd64f429e78. That's just a guess though. > > That makes no sense to me. The bug was reported (July 22) before the change was > merged (July 26). Okay, let's make that a really *bad* guess. I've been away for a week and didn't notice the chronology. This looks like an unrelated concurrency issue then.
bug 413551 is an interesting additional data point. Perhaps we're having a problem with loading the object itself from the file..
Actually, I think this might be the culprit. https://git.eclipse.org/r/#/c/14571/ cacad5cf5d03e0767114fbc0bf12145ba84da10a Basically, almost everything that is broken is broken currently is because we're not handling the eAdapters properly. I think that by running the change asynchronously, we're differing the concurrency issue until until later. I think I may have found the culprit, but I'm not sure yet. In GerritTaskDataHandler L136, we're calling AddObserver, which can change the adapters, but we aren't doing that from UI thread. I think that's the only case where this is occurring, but it would be enough to cause the failure we're seeing.
https://git.eclipse.org/r/14953 My concern is that we're now adding the adapters asynchronously (to rule-out potential deadlock). I need to ensure that there isn't the potential that we complete the retrieval before we get a chance to notify the observer.
(In reply to comment #5) > Actually, I think this might be the culprit. > https://git.eclipse.org/r/#/c/14571/ cacad5cf5d03e0767114fbc0bf12145ba84da10a I don't see how the change would cause the NPEs that are happening inside EMF. The change should ensure everything executes on the UI thread and hence fix that. > Basically, almost everything that is broken is broken currently is because we're > not handling the eAdapters properly. Yes. This needs to be fixed.
*** Bug 413479 has been marked as a duplicate of this bug. ***
*** Bug 413551 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > (In reply to comment #5) > > Actually, I think this might be the culprit. > > https://git.eclipse.org/r/#/c/14571/ cacad5cf5d03e0767114fbc0bf12145ba84da10a > > I don't see how the change would cause the NPEs that are happening inside EMF. > The change should ensure everything executes on the UI thread and hence fix > that. Right. I'd thought that this was being done async like the others but it's synchronous so the behavior shouldn't change WRT EMF. (In reply to comment #7) > (In reply to comment #5) > > Basically, almost everything that is broken is broken currently is because > we're > > not handling the eAdapters properly. > > Yes. This needs to be fixed. I have a radical proposal for fixing these issues that I'm working on. Review soon. I'm wondering if we should rename this bug to reflect the scope of that or start a new one..
(In reply to comment #10) > I have a radical proposal for fixing these issues that I'm working on. Review > soon. I'm wondering if we should rename this bug to reflect the scope of that or > start a new one.. Can you briefly describe the change that you are proposing before diving into too much implementation detail? I'm fine with renaming the bug but I'd prefer we take a look at the proposal (or review if that's indeed easiest) first.
(In reply to comment #11) > Can you briefly describe the change that you are proposing before diving into > too much implementation detail? I'm fine with renaming the bug but I'd prefer we > take a look at the proposal (or review if that's indeed easiest) first. Sure, was about to do that on the concurrency bug, but here works too. Basically, a lot of (all?) issues that we're running into have to do with the notificaiton mechansims, not actual changes to the underlying model. This is because we're constantly adding and removing ourselves from the list of adapters (this is just EMF speak for model-change-listener). The irony is that we don't even need to do this, because the Remote API is fully aware of the Remote life-cycle. The current design piggy-backs on the EMF notification mechanism with RemoteNotification. I did it this way because it was more generic and (I thought) elegant (all model adapaters receive remote notification and can decide wheter to handle them or not) but it's not really neccesary. Also, originally there wasn't a notion of a 1:1 correspondence between a Remote EMF Consumer and an EMF Model Object. So my proposal would be to chop out all of that RemoteNotification stuff. Then we don't need to worry about maintaining the adapters at all and we can support clean observer notification in any thread.
To summarize, you are proposing to replace the notification mechanism in RemoteEmfConsumer by a mechanism that doesn't rely on EMF? That sounds good to me.
(In reply to comment #13) > To summarize, you are proposing to replace the notification mechanism in > RemoteEmfConsumer by a mechanism that doesn't rely on EMF? That sounds good to > me. Basically, that's it. ;)
https://git.eclipse.org/r/#/c/15004/ As noted, WIP -- the tests pass but the runtime behavior looks pretty broken. (That say's a lot about the state of UI test coverage right there!) Comments much appreciated before I go farther down this road...
*** Bug 413774 has been marked as a duplicate of this bug. ***
Steffen, before you leave on vacation, can you give some guidance about whether the scope of changes in https://git.eclipse.org/r/#/c/15004/ are too large to include in 2.0.1 / Gerrit 2.6 support? My feeling is that we should solve this issue and this is likely to be the best way to do this properly but of course there is the possibility of new regressions. My next step would be to add some additional testing for the current behaviour as I'm seeing some issues that aren't currently covered and then return to the change above. (I ask because I have competing items on my agenda and I don't want to focus on it now, if it's not likely to make it in. :))
That's a tricky one. It breaks "API" and is a fundamental change but at the same time looks like the right way to address this problem. If you see a risk of introducing new regressions I'm -1 on including it in 2.0.1 and leaving the current bugs in there. Sam, do you have a sense of the frequency and impact of this bug? If it's severe enough we should still consider including the fix and work out any issues.
Looking at bug 413577 the impact is quite significant. Sam, Tomasz, thoughts on merging the change?
(In reply to comment #19) > Sam, Tomasz, thoughts on merging the change? Are you referring to https://git.eclipse.org/r/#/c/15004/ from comment 17 ?
(In reply to comment #20) > (In reply to comment #19) > > Sam, Tomasz, thoughts on merging the change? > > Are you referring to https://git.eclipse.org/r/#/c/15004/ from comment 17 ? Yes, sorry, that's the review I meant.
Commented on the change.
I don't think I see this issue often.
*** Bug 414460 has been marked as a duplicate of this bug. ***
Folks, the essential issue here is that the current notificaiton mechanism using EMF is broken because we're accessing it outside of the user thread. So I've renamed it since I can never find it -- hope that's ok. It is almost impossible from a maintenance POV to ensure that all usages are inside of UI *without* also risking deadlock. Given that, we need a better solution, which is what is proposed by https://git.eclipse.org/r/#/c/15004/. I'd like to get this change in shape for inclusion in 2.0.1 while leaving time for testing before release. If everyone is ok with the general approcah there, I'll refine the commit, add some more testing coverage, and hopefully we can get it in in next few days.
That sounds good to me. The only thing I'd ask for ask is a notification to mylyn-reviews-dev to keep consumers informed of the substantial/breaking change. Thanks for moving this forward. It's going to fix a number of problems which we can't fix reasonably with the current EMF-based strategy.
(In reply to comment #26) > That sounds good to me. The only thing I'd ask for ask is a notification to > mylyn-reviews-dev to keep consumers informed of the substantial/breaking change. Will do. > Thanks for moving this forward. It's going to fix a number of problems which we > can't fix reasonably with the current EMF-based strategy. Well, we'll chalk it up as a painful learning experience but that's part of what this effort was about I guess. Interesting that the notification mechanism ended up being the key issue.
*** Bug 413577 has been marked as a duplicate of this bug. ***
New tests to prevent regressions off of current master: https://git.eclipse.org/r/#/c/15490/
I am now frequently getting task editors with blank attributes. I think this is caused by this issue based on the errors in my log.
(In reply to comment #30) > I am now frequently getting task editors with blank attributes. I think this is > caused by this issue based on the errors in my log. Yikes. I'm a bit concerned that there might be some other condition that is triggering these..
Please review https://git.eclipse.org/r/#/c/15004/. :) See also: https://git.eclipse.org/r/#/c/15490/ Since it's testing only, I'll probably just merge it unless I hear objections. Note that while the builds are not being reported to Gerrit bug 415188, it appears that they are actually happening. So it's tedious, but you can verify them at https://hudson.eclipse.org/sandbox/job/mylyn-reviews-gerrit/
Note that the major thing I've done here is to remove the whole concept of notifying objects of child events. It turns out that we weren't really using it. However, there is one exception. When you open a patch set for a review that has a bad connection, you won't get notified that you can't get the patch set contents and there will not be a failure status in the related consumer. The reasons are sort of complicated, but I recall some discussion that makes me think this is perhaps a good thing, since the user already is notified of that issue at the Review level in any case. If people feel like we should address that, let's open a seperate bug (for > 2.0.1).
Tomasz reported on Gerrit: > Patch Set 7: > > Playing with the latest patch set I noticed two issues so far: > * Opening a review and closing it immediately leaves a warning in Task List: > "Couldn't retrieve remote object for... Check remote connection". My connection > is fine. (In reply to comment #22) > Patch Set 7: > > * Open a review, press Sync, close the editor => Error dialog with "Couldn't > retrieve remote object for task: 5958. Check remote connection", no stack trace. Please see https://git.eclipse.org/r/#/c/15004/7..8/org.eclipse.mylyn.gerrit.core/src/org/eclipse/mylyn/internal/gerrit/core/GerritTaskDataHandler.java for candidate fix. I was half serious in my Gerrit comment. It may be that the simplification is revealing some behaviour that was intermittent before but more consistently. Ok, this is what I believe is happening in both cases: 1) User triggers creation of observer when opening editor. 2) Immediately afterward, the Gerrit Task Handler getTaskData is called. However, seeing that a retrieval is (apparently) already in progress it simply waits for that retrieval to complete. 3) *Before* the observers are notified, the retrieve flag gets set to false. 4) Since in this case the gerrit task handler has not added an observer, when the task editor trigerred retrieval finishes, when it's observer is disposed, the consumer is also disposed, freeing the remote object. 5) The GerritTask Handler, seeing the remote object is null, set's the error code on the assumption that the retrieval failed, not realizing that the user simply cancelled the retrieval. Given all of this, I believe the correct thing to do is: To ensure that the GerritTaskHandler get's to see the actual RemoteObject register the observer even when a retrieval is already in progress. (I think we weren't doing this before because of a concern about possible dead-lock, but that should be safe now.)
Tomek also reported: (In reply to comment #21) > Patch Set 7: > * Now I can reproduce https://bugs.eclipse.org/bugs/show_bug.cgi?id=414461 quite > reliably, got 5 warnings in a row I *still* don't see that. Perhaps it is a Windows only thing.. See that bug.
*** Bug 415360 has been marked as a duplicate of this bug. ***
A similar stacktrace I have seen (same NPE, different path leading to it): org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NullPointerException) at org.eclipse.swt.SWT.error(SWT.java:4361) at org.eclipse.swt.SWT.error(SWT.java:4276) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4144) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3761) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124) 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:353) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180) 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:601) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at org.eclipse.equinox.launcher.Main.run(Main.java:1438) at org.eclipse.equinox.launcher.Main.main(Main.java:1414) Caused by: java.lang.NullPointerException at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:374) at org.eclipse.mylyn.reviews.internal.core.model.Review.setModificationDate(Review.java:326) at org.eclipse.mylyn.internal.gerrit.core.remote.GerritReviewRemoteFactory.updateModel(GerritReviewRemoteFactory.java:211) at org.eclipse.mylyn.internal.gerrit.core.remote.GerritReviewRemoteFactory.updateModel(GerritReviewRemoteFactory.java:1) at org.eclipse.mylyn.reviews.core.spi.remote.emf.RemoteEmfConsumer.applyModel(RemoteEmfConsumer.java:240) at org.eclipse.mylyn.reviews.core.spi.remote.JobRemoteService$3.run(JobRemoteService.java:95) at org.eclipse.ui.internal.UILockListener.doPendingWork(UILockListener.java:164) at org.eclipse.ui.internal.UISynchronizer$3.run(UISynchronizer.java:158) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) ... 23 more
Miles, are you still working on https://git.eclipse.org/r/#/c/15004/ ? If not someone else needs to take over. It's important that we get the fix in for 2.0.1 since there have been quite a few reports of this problem now.
I think Miles is on vacation and will be back Thursday. I agree that we need to resolve this for 2.0.1 since I am running into problems regularly.
(In reply to comment #39) > I am running into problems regularly. We all are ;) I will take a closer look and review https://git.eclipse.org/r/#/c/15004/ tmr.
Smoke testing https://git.eclipse.org/r/#/c/15004/8 , opening and closing a bunch of reviews at once: !ENTRY org.eclipse.mylyn.tasks.core 4 0 2013-08-21 18:10:05.814 !MESSAGE Synchronization failed !STACK 0 java.lang.NullPointerException at org.eclipse.mylyn.reviews.spi.edit.remote.AbstractRemoteEditFactoryProvider.close(AbstractRemoteEditFactoryProvider.java:239) at org.eclipse.mylyn.reviews.core.spi.remote.emf.RemoteEmfConsumer.dispose(RemoteEmfConsumer.java:251) at org.eclipse.mylyn.reviews.core.spi.remote.emf.RemoteEmfConsumer.release(RemoteEmfConsumer.java:294) at org.eclipse.mylyn.reviews.core.spi.remote.emf.RemoteEmfConsumer.removeObserver(RemoteEmfConsumer.java:289) at org.eclipse.mylyn.reviews.core.spi.remote.emf.RemoteEmfObserver.dispose(RemoteEmfObserver.java:83) at org.eclipse.mylyn.internal.gerrit.core.GerritTaskDataHandler.getTaskData(GerritTaskDataHandler.java:118) at org.eclipse.mylyn.internal.gerrit.core.GerritConnector.getTaskData(GerritConnector.java:157) at org.eclipse.mylyn.internal.tasks.core.sync.SynchronizeTasksJob.synchronizeTask(SynchronizeTasksJob.java:245) at org.eclipse.mylyn.internal.tasks.core.sync.SynchronizeTasksJob.runInternal(SynchronizeTasksJob.java:218) at org.eclipse.mylyn.internal.tasks.core.sync.SynchronizeTasksJob.run(SynchronizeTasksJob.java:153) at org.eclipse.mylyn.internal.tasks.core.sync.SynchronizeTasksJob.run(SynchronizeTasksJob.java:129) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) !ENTRY org.eclipse.mylyn.tasks.ui 4 0 2013-08-21 18:10:05.836 !MESSAGE Error opening task !STACK 1 org.eclipse.core.runtime.CoreException: Task data at "D:\workspace\eclipse\runtime-New_configuration\.metadata\.mylyn\tasks\org.eclipse.mylyn.gerrit-https%3A%2F%2Fgit.eclipse.org%2Fr\offline\4022.zip" not found at org.eclipse.mylyn.internal.tasks.core.data.TaskDataManager$1.execute(TaskDataManager.java:124) at org.eclipse.mylyn.internal.tasks.core.TaskList.run(TaskList.java:673) at org.eclipse.mylyn.internal.tasks.core.data.TaskDataManager.getWorkingCopy(TaskDataManager.java:119) at org.eclipse.mylyn.internal.tasks.core.data.TaskDataManager.getWorkingCopy(TaskDataManager.java:110) at org.eclipse.mylyn.tasks.ui.editors.AbstractTaskEditorPage.createModel(AbstractTaskEditorPage.java:733) at org.eclipse.mylyn.tasks.ui.editors.AbstractTaskEditorPage.initModel(AbstractTaskEditorPage.java:1281) at org.eclipse.mylyn.tasks.ui.editors.AbstractTaskEditorPage.init(AbstractTaskEditorPage.java:1273) at org.eclipse.mylyn.reviews.ui.spi.editor.AbstractReviewTaskEditorPage.access$1(AbstractReviewTaskEditorPage.java:1) at org.eclipse.mylyn.reviews.ui.spi.editor.AbstractReviewTaskEditorPage.init(AbstractReviewTaskEditorPage.java:66) at org.eclipse.ui.forms.editor.FormEditor.registerPage(FormEditor.java:657) at org.eclipse.ui.forms.editor.FormEditor.configurePage(FormEditor.java:348) at org.eclipse.ui.forms.editor.FormEditor.addPage(FormEditor.java:190) at org.eclipse.mylyn.tasks.ui.editors.TaskEditor.addPages(TaskEditor.java:410) at org.eclipse.ui.forms.editor.FormEditor.createPages(FormEditor.java:138) at org.eclipse.ui.forms.editor.SharedHeaderFormEditor.createPages(SharedHeaderFormEditor.java:98) at org.eclipse.mylyn.tasks.ui.editors.TaskEditor.createPages(TaskEditor.java:196) at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:348) at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:670) at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:465) at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:595) at org.eclipse.ui.internal.EditorReference.getEditor(EditorReference.java:289) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2958) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2863) at org.eclipse.ui.internal.WorkbenchPage.access$11(WorkbenchPage.java:2855) at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2806) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2802) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2786) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2769) at org.eclipse.mylyn.tasks.ui.TasksUiUtil.openEditor(TasksUiUtil.java:182) at org.eclipse.mylyn.internal.tasks.ui.util.TasksUiInternal.openTask(TasksUiInternal.java:924) at org.eclipse.mylyn.tasks.ui.TasksUiUtil.openTask(TasksUiUtil.java:283) at org.eclipse.mylyn.internal.tasks.ui.util.TasksUiInternal$3$1.run(TasksUiInternal.java:318) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4144) at org.eclipse.swt.widgets.Shell.WM_ENTERIDLE(Shell.java:2233) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4544) at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341) at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1627) at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2069) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4989) at org.eclipse.swt.internal.win32.OS.TrackPopupMenu(Native Method) at org.eclipse.swt.widgets.Menu._setVisible(Menu.java:257) at org.eclipse.swt.widgets.Display.runPopups(Display.java:4210) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3752) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124) 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:353) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180) 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:629) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at org.eclipse.equinox.launcher.Main.run(Main.java:1438) at org.eclipse.equinox.launcher.Main.main(Main.java:1414) !SUBENTRY 1 org.eclipse.mylyn.tasks.core 4 0 2013-08-21 18:10:05.837 !MESSAGE Task data at "D:\workspace\eclipse\runtime-New_configuration\.metadata\.mylyn\tasks\org.eclipse.mylyn.gerrit-https%3A%2F%2Fgit.eclipse.org%2Fr\offline\4022.zip" not found
I'm baaack! (I was waiting for review on this one in any case.) (In reply to comment #39) > I think Miles is on vacation and will be back Thursday. I agree that we need > to resolve this for 2.0.1 since I am running into problems regularly. (In reply to comment #41) > Smoke testing https://git.eclipse.org/r/#/c/15004/8 , opening and closing a > bunch of reviews at once: > > !ENTRY org.eclipse.mylyn.tasks.core 4 0 2013-08-21 18:10:05.814 > !MESSAGE Synchronization failed > !STACK 0 > java.lang.NullPointerException > at > org.eclipse.mylyn.reviews.spi.edit.remote.AbstractRemoteEditFactoryProvider. > close(AbstractRemoteEditFactoryProvider.java:239) That's "interesting". It looks like we have a resource that is no longer associated w/ a resource set. By itself, that just means we need a null check, but I'll want to take a bit > > !ENTRY org.eclipse.mylyn.tasks.ui 4 0 2013-08-21 18:10:05.836 > !MESSAGE Error opening task > !STACK 1 > org.eclipse.core.runtime.CoreException: Task data at > "D:\workspace\eclipse\runtime-New_configuration\.metadata\.mylyn\tasks\org. > eclipse.mylyn.gerrit-https%3A%2F%2Fgit.eclipse.org%2Fr\offline\4022.zip" not > found > at > org.eclipse.mylyn.internal.tasks.core.data.TaskDataManager$1. > execute(TaskDataManager.java:124) > at org.eclipse.mylyn.internal.tasks.core.TaskList.run(TaskList.java:673) > at > org.eclipse.mylyn.internal.tasks.core.data.TaskDataManager. > getWorkingCopy(TaskDataManager.java:119) Ok, no idea what's happening here. This is a Mylyn Task Data internal. Seems like almost a strange analog of what is happening above w/ the Reviews model side though, huh? I think the next step would be to try to determine what reviews these were for (if it is the same review then perhaps "4022") and examine that review file and see if we can find anything unusual. I'm going to go through the review comments now..
Just pushed new changes for https://git.eclipse.org/r/#/c/15490/ and https://git.eclipse.org/r/#/c/15004/
https://git.eclipse.org/r/#/c/15004/9 , opening Compare editor for a file from patch set: org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NullPointerException) at org.eclipse.swt.SWT.error(SWT.java:4361) at org.eclipse.swt.SWT.error(SWT.java:4276) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4144) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3761) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124) 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:353) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180) 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:629) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at org.eclipse.equinox.launcher.Main.run(Main.java:1438) at org.eclipse.equinox.launcher.Main.main(Main.java:1414) Caused by: java.lang.NullPointerException at org.eclipse.mylyn.internal.gerrit.core.remote.GerritReviewRemoteFactory.updateModel(GerritReviewRemoteFactory.java:202) at org.eclipse.mylyn.internal.gerrit.core.remote.GerritReviewRemoteFactory.updateModel(GerritReviewRemoteFactory.java:1) at org.eclipse.mylyn.reviews.core.spi.remote.emf.RemoteEmfConsumer.applyModel(RemoteEmfConsumer.java:183) at org.eclipse.mylyn.reviews.core.spi.remote.JobRemoteService$3.run(JobRemoteService.java:95) at org.eclipse.ui.internal.UILockListener.doPendingWork(UILockListener.java:164) at org.eclipse.ui.internal.UISynchronizer$3.run(UISynchronizer.java:158) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) ... 23 more
Created attachment 234663 [details] screenshot of blank editor https://git.eclipse.org/r/#/c/15004/9 , after cancelling a long running task retrieval. Same exception as above.
And I'm still able to get the the _Parent and local keys must be specified_ exception, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=410580#c17
(In reply to comment #44) > https://git.eclipse.org/r/#/c/15004/9 , opening Compare editor for a file from > patch set: ... > Caused by: java.lang.NullPointerException > at > org.eclipse.mylyn.internal.gerrit.core.remote.GerritReviewRemoteFactory.updateModel(GerritReviewRemoteFactory.java:202) > at > org.eclipse.mylyn.internal.gerrit.core.remote.GerritReviewRemoteFactory.updateModel(GerritReviewRemoteFactory.java:1) > at > org.eclipse.mylyn.reviews.core.spi.remote.emf.RemoteEmfConsumer.applyModel(RemoteEmfConsumer.java:183) > at > org.eclipse.mylyn.reviews.core.spi.remote.JobRemoteService$3.run(JobRemoteService.java:95) > at > org.eclipse.ui.internal.UILockListener.doPendingWork(UILockListener.java:164) > at org.eclipse.ui.internal.UISynchronizer$3.run(UISynchronizer.java:158) > at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) > at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) > ... 23 more That looks similar to bug 410597: [regression] NPE when querying and configuration is not cached.
If I cancel retrieval of a patch set and then select the Fetch button I get the following exception: java.lang.NullPointerException at org.eclipse.mylyn.internal.gerrit.ui.factories.AbstractPatchSetUiFactory.getGitRepository(AbstractPatchSetUiFactory.java:105) at org.eclipse.mylyn.internal.gerrit.ui.factories.FetchUiFactory.execute(FetchUiFactory.java:32) at org.eclipse.mylyn.reviews.ui.spi.factories.AbstractUiFactory.handleExecute(AbstractUiFactory.java:81) at org.eclipse.mylyn.reviews.ui.spi.factories.AbstractUiFactory.access$0(AbstractUiFactory.java:79) at org.eclipse.mylyn.reviews.ui.spi.factories.AbstractUiFactory$1.widgetSelected(AbstractUiFactory.java:72)
(In reply to comment #44) > https://git.eclipse.org/r/#/c/15004/9 , opening Compare editor for a file from > patch set: > > Caused by: java.lang.NullPointerException > at > org.eclipse.mylyn.internal.gerrit.core.remote.GerritReviewRemoteFactory.updateModel(GerritReviewRemoteFactory.java:202) > at > org.eclipse.mylyn.internal.gerrit.core.remote.GerritReviewRemoteFactory.updateModel(GerritReviewRemoteFactory.java:1) I can't reproduce this..and I am able to compare files. Looks like the GerritConfiguration is perhaps missing..? Is this a general problem or something you saw only on a specific patch set?
(In reply to comment #45) > Created attachment 234663 [details] > screenshot of blank editor > > https://git.eclipse.org/r/#/c/15004/9 , after cancelling a long running task > retrieval. Same exception as above. Again, I'm not seeing anything like this. Hmm..
(In reply to comment #47) > That looks similar to bug 410597: [regression] NPE when querying and > configuration is not cached. Yeah. I'm not sure how/if this change has somehow revealed made this issue more repeatable or what. Tomek, can you reproduce this off of master as well?
(In reply to comment #48) > If I cancel retrieval of a patch set and then select the Fetch button I get the > following exception: > > java.lang.NullPointerException > at > org.eclipse.mylyn.internal.gerrit.ui.factories.AbstractPatchSetUiFactory.getGitRepository(AbstractPatchSetUiFactory.java:105) Actually, I think this is just a bug in the FetchUIFactory. It's assuming that we can fetch in all cases, but we can't fetch if we don't have the remote object. I don't think it's relevant to this change in particular. (We probably just made the issue more apparant.) I've filed bug 415703.
Merged https://git.eclipse.org/r/#/c/15004/ and https://git.eclipse.org/r/#/c/15490/. Please open new bugs for anything that hasn't been responded to above.
