Community
Participate
Working Groups
My eclipse has started hanging while debugging forcing me to kill eclipse. javacore dumps always show the main thread performing debug updates: "main" J9VMThread:0x00000000032C9A00, omrthread_t:0x0000000001126D90, java/lang/Thread:0x000000009A8D03D0, state:R, prio=6 Java callstack: at org/eclipse/jface/viewers/TreePath.equals(TreePath.java:156(Compiled Code)) at org/eclipse/jface/viewers/TreePath.equals(TreePath.java:106(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/TreeModelLabelProvider.cancelPathUpdates(TreeModelLabelProvider.java:300(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/TreeModelLabelProvider.update(TreeModelLabelProvider.java:265(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/InternalTreeModelViewer.doUpdateItem(InternalTreeModelViewer.java:1095(Compiled Code)) at org/eclipse/jface/viewers/AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:121(Compiled Code)) at org/eclipse/core/runtime/SafeRunner.run(SafeRunner.java:45(Compiled Code)) at org/eclipse/ui/internal/JFaceUtil.lambda$0(JFaceUtil.java:47(Compiled Code)) at org/eclipse/ui/internal/JFaceUtil$$Lambda$34/00000000132A6180.run(Bytecode PC:1(Compiled Code)) at org/eclipse/jface/util/SafeRunnable.run(SafeRunnable.java:174(Compiled Code)) at org/eclipse/jface/viewers/AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:1024(Compiled Code)) at org/eclipse/jface/viewers/StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:422(Compiled Code)) at org/eclipse/core/runtime/SafeRunner.run(SafeRunner.java:45(Compiled Code)) at org/eclipse/ui/internal/JFaceUtil.lambda$0(JFaceUtil.java:47(Compiled Code)) at org/eclipse/ui/internal/JFaceUtil$$Lambda$34/00000000132A6180.run(Bytecode PC:1(Compiled Code)) at org/eclipse/jface/util/SafeRunnable.run(SafeRunnable.java:174(Compiled Code)) at org/eclipse/jface/viewers/StructuredViewer.updateItem(StructuredViewer.java:2097(Compiled Code)) at org/eclipse/jface/viewers/StructuredViewer.internalUpdate(StructuredViewer.java:2080(Compiled Code)) at org/eclipse/jface/viewers/StructuredViewer.update(StructuredViewer.java:2021(Compiled Code)) at org/eclipse/jface/viewers/ColumnViewer.update(ColumnViewer.java:545(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/InternalTreeModelViewer.update(InternalTreeModelViewer.java:1380(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/TreeModelContentProvider.handleState(TreeModelContentProvider.java:1667(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/TreeModelContentProvider.updateNodes(TreeModelContentProvider.java:1278(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/TreeModelContentProvider.updateNodes(TreeModelContentProvider.java:1305(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/TreeModelContentProvider.updateNodes(TreeModelContentProvider.java:1305(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/TreeModelContentProvider.updateNodes(TreeModelContentProvider.java:1305(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/TreeModelContentProvider.updateModel(TreeModelContentProvider.java:563(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/TreeModelContentProvider.doModelChanged(TreeModelContentProvider.java:530(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/TreeModelContentProvider.access$0(TreeModelContentProvider.java:524(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/TreeModelContentProvider$DelayedDoModelChangedJob.runInUIThread(TreeModelContentProvider.java:436(Compiled Code)) "main" J9VMThread:0x00000000032C9A00, omrthread_t:0x0000000001126D90, java/lang/Thread:0x000000009A8D03D0, state:R, prio=6 Java callstack: at org/eclipse/debug/internal/ui/viewers/model/TreeModelLabelProvider.cancelElementUpdates(TreeModelLabelProvider.java:357(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/TreeModelLabelProvider.access$0(TreeModelLabelProvider.java:356(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/TreeModelLabelProvider$CancelPendingUpdatesVisitor.visit(TreeModelLabelProvider.java:117(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/provisional/ModelDelta.doAccept(ModelDelta.java:378(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/provisional/ModelDelta.doAccept(ModelDelta.java:381(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/provisional/ModelDelta.doAccept(ModelDelta.java:381(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/provisional/ModelDelta.doAccept(ModelDelta.java:381(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/provisional/ModelDelta.accept(ModelDelta.java:374(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/TreeModelLabelProvider.modelChanged(TreeModelLabelProvider.java:508(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/TreeModelContentProvider.doModelChanged(TreeModelContentProvider.java:537(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/TreeModelContentProvider.access$0(TreeModelContentProvider.java:524(Compiled Code)) at org/eclipse/debug/internal/ui/viewers/model/TreeModelContentProvider$DelayedDoModelChangedJob.runInUIThread(TreeModelContentProvider.java:436(Compiled Code))
This was running I20191007-1800
Raising to major because this makes Eclipse unusable for me. A heap dump shows TreeModelContentProvider.DelayedDoModelChangedJob contains an ArrayList with 540,217 elements of type DelayedDoModelChange. The JobManager is perhaps blocked and is holding 932k jobs
Are you using Windows 10? Did you disable Windows defender for Eclipse? https://www.eclipse.org/eclipse/news/4.14/
I am on windows 10, but I have added my eclipse installs and workspaces to the defender exclusion list. I did notice the eclipse slowdown when I first upgraded to windows 10, but I did not experience this debug hang until recently. I can't say if this is a problem in 4.13, I only ran that release for a short time before upgrading to a 4.14 IBuild due to crashes in swt. I don't think I ever saw this problem in 4.12. I have now reverted to 4.13 with a patched swt.
(In reply to Andrew Niefer from comment #1) > This was running I20191007-1800 Which was the first build you saw the regression? Could be bug 550220 (merged in I20191016-1800). If you could either provide steps to reproduce or bisect to the first failing build, it would greatly simplify our work :-)
I have gone back to the 4.13 release and still have the problem there. The problem may not be new, but may be more related to the process I am debugging. In the last couple of days where I am hitting the problem quite reliably, while debugging the same problem. The process I am debugging is changing thread names very rapidly, I not sure what else it might be doing that issues so many debug events. My latest heap dump shows org.eclipse.ui.internal.progress.ProgressMonitor holding ~215k jobs of org.eclipse.debug.core.commands.AbstractDebugCommand$UpdateJob. Also, the TreeModelContentProvider#DelayedDoModelChangedJob contains almost 40k DelayedDoModelChange objects.
Sorry, my last comment should have said that I have gone back to 4.12
I modified my local install by changing DelayedDoModelChangedJob.runDelayed to only add the task to the queue if (fQueue.size() < 2048) With this change, I no longer experience the same kind of hangs. I'm fairly sure that the hangs start in a section of the debugged process that results in a large number of rapid changes to the thread name. My change may not be a valid fix, I don't know what the consequence of dropping tasks is, but it makes things usable for me when this happens. I'm fine with reducing the severity of this defect back to normal.
This can be related to the change for displaying the thread names in the Debug view introduced in 4.8 Bug 528808. You can try setting org.eclipse.jdt.debug.ui/org.eclipse.jdt.debug.ui.javaDebug.ListenOnThreadNameChanges=false https://www.eclipse.org/eclipse/news/4.8/jdt.php#worker-deobfuscated-jdt
The property in comment 9 does not appear to exist anymore, instead there is a system property "org.eclipse.jdt.internal.debug.core.model.ThreadNameChangeListener.disable". Disabling "Show running threads" in the debug view makes the problem go away. I modified my ThreadNameChangeHandler from jdt to fire the debug event only if more than 2ms has passed since the last time. With this change, eclipse remained responsive throughout the thread name spamming. As would be expected, I do notice occasionally a thread name will remain the same for a while, particularly if more than one thread is having its name spammed.
(In reply to Andrew Niefer from comment #10) > I modified my ThreadNameChangeHandler from jdt to fire the debug event only > if more than 2ms has passed since the last time. > > With this change, eclipse remained responsive throughout the thread name > spamming. As would be expected, I do notice occasionally a thread name will > remain the same for a while, particularly if more than one thread is having > its name spammed. Do you want/plan to contribute this as Gerrit patch?
(In reply to Andrey Loskutov from comment #11) > Do you want/plan to contribute this as Gerrit patch? It is not clear to me that I'm allowed to contribute patches. I'm not actually an employee of IBM, I'm a contractor. My actual employer has not signed a consent, I think my commit rights were suspended. I think I only have the green eca check mark because I have an ibm email.
(In reply to Andrew Niefer from comment #12) > (In reply to Andrey Loskutov from comment #11) > > Do you want/plan to contribute this as Gerrit patch? > > It is not clear to me that I'm allowed to contribute patches. > > I'm not actually an employee of IBM, I'm a contractor. My actual employer > has not signed a consent, I think my commit rights were suspended. I think > I only have the green eca check mark because I have an ibm email. IBM email does not ensure the green check mark. With the new open source policies of IBM, you should be able to contribute the patch. you can check with your manager. @Andrey, Can you please update the system property name in N&N ?
As we have alternate solution, changing the bug to Normal.
(In reply to Sarika Sinha from comment #13) > @Andrey, > Can you please update the system property name in N&N ? The N&N in 4.8 is OK, we have re-defined this in 4.9, see bug 536053 and https://www.eclipse.org/eclipse/news/4.9/jdt.php#disable-thread-name-changes Regarding the patch for *this* bug: Andrew: with the green ECA badge status you should be able to push the patch to Gerrit.
Andrey, there are a few instances of combining debug view updates into a bulk update. I don't know how the thread name changes are propagated, but it might make sense to see if we can combine those as well. Only the last change would matter if we can do this. If possible, it would be better than reacting to a changed thread name only if X milliseconds have passed since the last update.
(In reply to Simeon Andreev from comment #16) > Andrey, there are a few instances of combining debug view updates into a > bulk update. I don't know how the thread name changes are propagated, but it > might make sense to see if we can combine those as well. > > Only the last change would matter if we can do this. If possible, it would > be better than reacting to a changed thread name only if X milliseconds have > passed since the last update. Right, sounds better.
*** Bug 552563 has been marked as a duplicate of this bug. ***
What about ThreadNameChangeHandler having a private Set<JDIThread> pendingThreadNamingUpdates = new HashSet<>(); then all #handleEvent does is adding to pendingThreadNamingUpdates Addtionally ThreadNameChangeHandler would require a Thread which periodically ( period to be defined, 1sec, I guess even 5sec would be ok? )converts the JDIThreads in pendingThreadNamingUpdates into DebugEvents which are then fired/handled by one single DebugPlugin.getDefault().fireDebugEventSet( <gathered DebugEvents> ); and after that empties the pendingThreadNamingUpdates. Concurrency of pendingThreadNamingUpdates not yet considered, synchronized( pendingThreadNamingUpdates ) { ... } being one
(In reply to Clemens Wyss from comment #19) > What about ThreadNameChangeHandler having a > private Set<JDIThread> pendingThreadNamingUpdates = new HashSet<>(); > > then all #handleEvent does is adding to pendingThreadNamingUpdates > > Addtionally ThreadNameChangeHandler would require a Thread which > periodically ( period to be defined, 1sec, I guess even 5sec would be ok? > )converts the JDIThreads in pendingThreadNamingUpdates into DebugEvents > which are then fired/handled by one single > DebugPlugin.getDefault().fireDebugEventSet( <gathered DebugEvents> ); > and after that empties the pendingThreadNamingUpdates. > > Concurrency of pendingThreadNamingUpdates not yet considered, > synchronized( pendingThreadNamingUpdates ) { ... } > being one I have already patch in the work, will share soon. Right now I see that 5 ms is too small if I spam Eclipse with 100 threads without a pause, 10 ms seems to be OK for my config (VM running on 8 cores, 32 GB RAM).
Created attachment 280488 [details] Reproducer Don't try the attachment with unpatched Eclipse, it will freeze.
New Gerrit change created: https://git.eclipse.org/r/151885
(In reply to Andrey Loskutov from comment #20) > I have already patch in the work, will share soon. perfect! >10 ms seems to be OK why so "low"? Can anybody notice these frequent changes (100/s) in the debug view?
(In reply to Clemens Wyss from comment #23) > (In reply to Andrey Loskutov from comment #20) > > I have already patch in the work, will share soon. > perfect! > > >10 ms seems to be OK > why so "low"? Can anybody notice these frequent changes (100/s) in the debug > view? It is less about frequency, it is about perceived debugger responsiveness. I'm fine with something below 50 ms, but probably not more, otherwise users will start to notice that we are cheating :-)
(In reply to Andrey Loskutov from comment #24) > otherwise users will start to notice that we are cheating :-) well, we are "cheating" ;-) Why not make the frequency a config-param? org.eclipse.jdt.internal.debug.core.model.ThreadNameChangeListener.updateFrequencyInMs
Gerrit change https://git.eclipse.org/r/151885 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=73ab3a9e2bd0c1a0066b6715f0f9a3047e1d52d3
(In reply to Eclipse Genie from comment #26) > Gerrit change https://git.eclipse.org/r/151885 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/ > ?id=73ab3a9e2bd0c1a0066b6715f0f9a3047e1d52d3 Andrew, Clemens: could you please check if this build works for you (without VM option) : http://download.eclipse.org/eclipse/downloads/drops4/I20191101-1800/
seems to "work" :thumbup: A question of clarification (being unaware of Eclipse Job scheduling): >schedule(delay) Wouldn't/doesn't that fill the "job schedule", or can a job be scheduled at most once, i.e. the effective next schedule time is postponed again and again? If "at most once" and we have "a long running period of different thread being renamed over and over" won't we be seeing no updates for a long time?
(In reply to Clemens Wyss from comment #28) > seems to "work" :thumbup: > > A question of clarification (being unaware of Eclipse Job scheduling): > >schedule(delay) > Wouldn't/doesn't that fill the "job schedule", or can a job be scheduled at > most once, i.e. the effective next schedule time is postponed again and > again? If "at most once" and we have "a long running period of different > thread being renamed over and over" won't we be seeing no updates for a long > time? See https://help.eclipse.org/2019-09/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/runtime/jobs/Job.html#schedule(long)
Can we resolve this bug now?
(In reply to Sarika Sinha from comment #30) > Can we resolve this bug now? Thanks for reminder, waited for the feedback from Andrew. From my POV yes. Andrew, please reopen if you have a good reason :-)
unfortunately I am reseeing this issue in Eclipse 4.21 Eclipse Platform Version: 2021-09 (4.21) Build id: I20210729-1800 Eclipse freezes being >99% in org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateNodes () 447'889 ms (99.1 %) 447'889 ms (99.1 %) Example of callstack: "main" #1 prio=6 os_prio=0 cpu=867515.63ms elapsed=4578.76s tid=0x0000024a6169f800 nid=0x22d4 runnable [0x000000c41115d000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.win32.OS.SendMessage(Native Method) at org.eclipse.swt.widgets.Tree.findItem(Tree.java:2861) at org.eclipse.swt.widgets.TreeItem.getItem(TreeItem.java:720) at org.eclipse.jface.viewers.TreeViewer.replace(TreeViewer.java:464) at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.handleAdd(TreeModelContentProvider.java:1345) at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateNodes(TreeModelContentProvider.java:1263) at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateNodes(TreeModelContentProvider.java:1299) at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateNodes(TreeModelContentProvider.java:1299) at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateNodes(TreeModelContentProvider.java:1299) at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateModel(TreeModelContentProvider.java:563) at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.doModelChanged(TreeModelContentProvider.java:530) at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider$DelayedDoModelChangedJob.runInUIThread(TreeModelContentProvider.java:436) at org.eclipse.ui.progress.UIJob.lambda$0(UIJob.java:95) at org.eclipse.ui.progress.UIJob$$Lambda$823/0x0000024a023410a8.run(Unknown Source) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185) - locked <0x0000024b2d4bdc98> (a org.eclipse.swt.widgets.RunnableLock) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4029) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3629) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1150) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1041) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:644) at org.eclipse.ui.internal.Workbench$$Lambda$204/0x0000024b70ea40a8.run(Unknown Source) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:551) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:156) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:136) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.11/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.11/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.11/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base@11.0.11/Method.java:566) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:654) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591) at org.eclipse.equinox.launcher.Main.run(Main.java:1462)
