Community
Participate
Working Groups
I got the following log after I accidentally made a query for all open Mylyn bugs. This query only contained 915 tasks, but froze the UI so that eclipse was unusable and eventually crashed due to the OutOfMemoryError. -- Error Log -- Date: Wed Oct 24 10:39:52 PDT 2007 Message: An internal error occurred during: "Synchronizing queries for Eclipse.org". Severity: Error Plugin ID: org.eclipse.core.jobs Stack Trace: java.lang.OutOfMemoryError: Java heap space After some diagnosis, the UI starts slowing down when it is synchronizing the changed tasks. The tasklist view seems to be refreshing itself constantly, but I am unsure of where it is being triggered from as it seems to be run in an async exec. I will investigate this some more and post if I find anything. Here is the stack trace from the main thread: Thread [main] (Suspended) OS.SendMessageW(int, int, int, int) line: not available [native method] OS.SendMessage(int, int, int, int) line: 2901 Tree.getItems(int) line: 3133 TreeItem.getItems() line: 775 FilteredTree$NotifyingTreeViewer(TreeViewer).getChildren(Widget) line: 155 FilteredTree$NotifyingTreeViewer(AbstractTreeViewer).updateChildren(Widget, Object, Object[], boolean) line: 2512 FilteredTree$NotifyingTreeViewer(AbstractTreeViewer).internalRefreshStruct(Widget, Object, boolean) line: 1829 FilteredTree$NotifyingTreeViewer(TreeViewer).internalRefreshStruct(Widget, Object, boolean) line: 704 FilteredTree$NotifyingTreeViewer(AbstractTreeViewer).internalRefreshStruct(Widget, Object, boolean) line: 1836 FilteredTree$NotifyingTreeViewer(TreeViewer).internalRefreshStruct(Widget, Object, boolean) line: 704 FilteredTree$NotifyingTreeViewer(AbstractTreeViewer).internalRefresh(Widget, Object, boolean, boolean) line: 1804 FilteredTree$NotifyingTreeViewer(AbstractTreeViewer).internalRefresh(Object, boolean) line: 1760 StructuredViewer$8.run() line: 1460 FilteredTree$NotifyingTreeViewer(StructuredViewer).preservingSelection(Runnable, boolean) line: 1368 FilteredTree$NotifyingTreeViewer(TreeViewer).preservingSelection(Runnable, boolean) line: 390 FilteredTree$NotifyingTreeViewer(StructuredViewer).preservingSelection(Runnable) line: 1330 FilteredTree$NotifyingTreeViewer(StructuredViewer).refresh(Object, boolean) line: 1458 FilteredTree$NotifyingTreeViewer(ColumnViewer).refresh(Object, boolean) line: 547 FilteredTree$NotifyingTreeViewer.refresh(Object, boolean) line: 823 FilteredTree$NotifyingTreeViewer(StructuredViewer).refresh(boolean) line: 1415 FilteredTree$NotifyingTreeViewer.refresh(boolean) line: 813 TaskListView.refresh(AbstractTaskContainer) line: 1488 TaskListView.refreshTask(TaskContainerDelta) line: 1630 TaskListView.access$4(TaskListView, TaskContainerDelta) line: 1623 TaskListView$4$1.run() line: 443 RunnableLock.run() line: 35 UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 123 Display.runAsyncMessages(boolean) line: 3659 Display.readAndDispatch() line: 3296 Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2389 Workbench.runUI() line: 2353 Workbench.access$4(Workbench) line: 2219 Workbench$4.run() line: 466 Realm.runWithDefault(Realm, Runnable) line: 289 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 461 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 IDEApplication.start(IApplicationContext) line: 106 EclipseAppHandle.run(Object) line: 169 EclipseAppLauncher.runApplication(Object) line: 106 EclipseAppLauncher.start(Object) line: 76 EclipseStarter.run(Object) line: 363 EclipseStarter.run(String[], Runnable) line: 176 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: not available DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not available Method.invoke(Object, Object...) line: not available Main.invokeFramework(String[], URL[]) line: 508 Main.basicRun(String[]) line: 447 Main.run(String[]) line: 1173 Main.main(String[]) line: 1148
It turns out that the problem is in: TasklistView.refreshTask(TaskContainerDelta taskContainerDelta) As the query is sync'ing, it will continuously refresh the entire tasklist, causing the UI to block.
Without additional information it's not clear that this is a blocker, because there is a clear work-around (increase memory or create smaller queries). We need to figure out why we would be getting an OutOfMemoryException, since that seems unrelated to refresh. Will investigate further.
I may have to agree that the out of memory error part of this bug is not a blocker since there is no clear information about why it happened, but the UI freeze due to creating a query is a bad regression. Should I open a new bug for that then?
I haven't seen the OOMEs, but I can confirm that UI does stop responding on any async actions because of the refresh event storm from the query synchronization (probably even by the one that does check if archived tasks been updated). Also, I noticed another weird refresh-related bug. Say you select bunch of incoming changes (somewhere more then 40) and mark them as read. Then the Task List view flickering for quite some time (it look like a task is being inserted and then quickly removed again and again). Not sure if it only happens when there is a query is running for the same bugzilla repository and I noticed it with bugzilla, but not sure if it is also the same for other repositories.
Is this the same as bug 207271: Mylyn spends long time checking eclipse.org even when no queries are defined?
No, this is different. This is a UI refresh bug that can manifest itself with any repository kind not only bugzilla (as it turned out).
This could be same as bug 207384.
(In reply to comment #7) > This could be same as bug 207384. This one is UI refresh + events, and bug 207384 is purely about memory structures. Though both are bad.
From what I can tell from my stack trace analysis a UI refresh can trigger the call mentioned on bug 207384. That call allocates up to a 100 MB of memory for my task list. I find it very likely that these reports are related. I can provide a memory snapshot if anybody wants to verify that.
They are related of course, but they can be fixed separately, i.e. getChildren() can be called not only from UI refresh. BTW, is 100Mb of objects been allocated and kept in memory or it is a sum of short living objects that shortly GCed? While latter can be annoying, modern JVMs handle it quite well.
(In reply to comment #10) > BTW, is 100Mb of objects been allocated and kept in memory or it is a sum of > short living objects that shortly GCed? While latter can be annoying, modern > JVMs handle it quite well. The objects are disposed but the garbage collection slows down Eclipse to a point where it becomes very unresponsive.
I have attached a patch to bug 194430 to address the refresh performance problem. I don't have any pointers what is causing the OOM exception at this point. The problems discussed in previous comments are related to SOAP requests which does not apply to Bugzilla.
Thanks Steffen. If anyone notices any of these problems please reopen. Fyi, I saw my VM eat up it's full heap space today when an extension of Mylyn malfunctioned on startup, causing a broken initialization, and the Task List was synchronizing. SendSignal didn't help other than to note that refresh was happening. Haven't noticed anything of this sort with a proper startup. *** This bug has been marked as a duplicate of bug 194430 ***
