Community
Participate
Working Groups
I started up in a clean workspace running on the latest and added a repository and a query and I keep getting an error syncing the query: Error Tue Jul 23 13:35:19 PDT 2013 Synchronization failed java.lang.NullPointerException There is no stack trace. This happens for both 2.6.1 and 2.4.1.
This also happens when syncing individual tasks.
After restarting, I now get 2 more NPEs in addition: Caused by: java.lang.NullPointerException at org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapterList.didRemove(BasicNotifierImpl.java:146) at org.eclipse.emf.common.util.BasicEList.remove(BasicEList.java:616) at org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapterList.remove(BasicNotifierImpl.java:221) at org.eclipse.emf.common.util.AbstractEList.remove(AbstractEList.java:460) at org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapterList.remove(BasicNotifierImpl.java:214) at org.eclipse.mylyn.reviews.core.spi.remote.emf.RemoteEmfConsumer$5.run(RemoteEmfConsumer.java:319) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) 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.NotificationImpl.dispatch(NotificationImpl.java:1032) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.remove(NotifyingListImpl.java:718) 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.internal.gerrit.core.GerritTaskDataHandler.getTaskData(GerritTaskDataHandler.java:125) at org.eclipse.mylyn.internal.gerrit.core.GerritConnector.getTaskData(GerritConnector.java:157)
Also, when I sync a query, mark all tasks read, and sync again, a bunch of tasks get marked unread. This seems to happen the first several times I sync a query and then it stops.
We may need to add some diagnostics here. I think we can treat these all as dups, but I'll wait on that until I have a better idea of the cause.
Looking at the stack trace there is access to the model and resources from a thread that is not the UI thread. This can cause all kinds of corruption and problems and is similar to bug
Yep. This is essentailly the same issue as bug 413480, I believe, though it's possible that there is something else going on here too. I'm a little concerned because I can't think of how this issue might be persisting in the way it seems to be in Sam's environment. My assumption was that any resulting issues from the notificaiton mechanism should be more tranisent in nature. So let's not mark this one as a dup yet.
I don't understand how we could get an NPE with no stack trace. It might not be related to comment 2. Note that this all happened in a *clean workspace*, i.e. it had never had any previous version of the connector installed.
Ok, then let's drop comment 2 from dicussion, as I think it might be unrelated. This is weird. An exception is getting swallowed (or nibbled at anyway) somewhere. I'ma ssuming that you didn't have any proximate NPEs in the log w/ the original issue or you would have reported those.
Miles, this looks like a different problem than bug 413480 even though somewhat similar in natrue. AbstractRemoteEditFactoryProvider.save() persists the model in a job. Is there any guard in place that would prevent the UI thread from reading the model at the same time or other threads to write to the same model?
As discussed, let's ignore comment 9 for now since it's not clear if that would cause actual problems. We don't have a good way to diagnose the logged NPE further. I'm assuming that it's the same error as in comment 2 which looks like a duplicate of bug 413480. Sam, please reopen if you see this again after the fix for bug 413480 is merged so we can look into this further. *** This bug has been marked as a duplicate of bug 413480 ***
Ok. I can't reproduce it now. It might have been caused by some plugin being missing from my run configuration.
(In reply to comment #9) > Miles, this looks like a different problem than bug 413480 even though somewhat > similar in natrue. AbstractRemoteEditFactoryProvider.save() persists the model > in a job. Is there any guard in place that would prevent the UI thread from > reading the model at the same time or other threads to write to the same model? To answer your insightful concern in comment 9: Initially, there was a general assumption that all of this would be happening on the UI thread, which is no longer the case after bug 409343 moved the update to the general Mylyn Task update mechanism. But there was also an (indirect) mechanism in the design to prevent this from happening, and in retrospect that's what I was getting at w/ my bug 413571 comment 9. This was how it was supposed to be happening: In addition 1. Saves happen a) when explicitly requested (only on UI thread) or when all consumers have been disposed. 2. Consumers could only be disposed when the last observer has been removed. 3. To prevent this from happening, the remote observers were synchronized. (However, that wasn't actually completely prevented, as the dispose itself was only delayed, not guarded against remote observers. (It happened a line after the lock was released.) However, the changes in bug 413571 removed (3). This was my intuition in bug 413571 comment 9 and bug 413480 comment 1. However, as Steffen pointed out, that concern is bogus, given Tomek's change happened *after* bug 413480 was reported. (By one day.) This leaves us w/ perhaps the possibility that we could have multiple objects (reviews) open w/ the same underlying resource in the case where we a) save a file and at the same time b) open the file from another thread. However, the open would be protected from corruption by AbstractRemoteEditFactoryProvider L 142. So the worst case (I believe) is that we'd have two objects for the same review in memory, with the possiblity of overwriting local changes. Whew, got all that? It's still early in the morning so my analysis could be screwy, but the upshot is that it might be a legitimate concern.
(In reply to comment #12) > This leaves us w/ perhaps the possibility that we could have multiple objects > (reviews) open w/ the same underlying resource in the case where we a) save a > file and at the same time b) open the file from another thread. However, the > open would be protected from corruption by AbstractRemoteEditFactoryProvider L > 142. So the worst case (I believe) is that we'd have two objects for the same > review in memory, with the possiblity of overwriting local changes. And thinking about this a bit further, this would only be an issue if some object hung on to a reference to a particular review for some reason. This should not be happening, as consumers (in the API sense!) should normally be getting the review directly from the consumer, and there should be one and only one of those for any given review (i.e. local and/or remote key).
