Community
Participate
Working Groups
Created attachment 284267 [details] Threaddump 1 there was https://bugs.eclipse.org/bugs/show_bug.cgi?id=552328 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=552563 in which I was involved too ;) As of Eclipse Platform Version: 2020-12 (4.18) Build id: I20200922-1800 I am facing this "issue" again Find attached 3 threaddumps (taken with VisualVM) when Eclipse "hangs" Former environment variable -Dorg.eclipse.jdt.internal.debug.core.model.ThreadNameChangeListener.disable=true does not seem to help
Created attachment 284268 [details] Threaddump 2
Created attachment 284269 [details] Threaddump 3
(no big suprise) closing the Debug View helps
The dumps are showing same picture, the UI hangs in Tree.getSelection How many threads do you have? Some thousands? "main" #1 prio=6 os_prio=0 cpu=1476718.75ms elapsed=101538.24s tid=0x000000000371b000 nid=0x37cc runnable [0x000000000095c000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.win32.OS.SendMessage(Native Method) at org.eclipse.swt.widgets.Tree.getSelection(Tree.java:3426) at org.eclipse.swt.widgets.Tree.getSelection(Tree.java:3446) at org.eclipse.swt.widgets.Tree.getSelection(Tree.java:3446) at org.eclipse.swt.widgets.Tree.getSelection(Tree.java:3496) at org.eclipse.jface.viewers.TreeViewer.getSelection(TreeViewer.java:231) at org.eclipse.jface.viewers.TreeViewer.setSelection(TreeViewer.java:308) at org.eclipse.jface.viewers.AbstractTreeViewer.setSelectionToWidget(AbstractTreeViewer.java:2571) at org.eclipse.jface.viewers.AbstractTreeViewer.setSelectionToWidget(AbstractTreeViewer.java:3027) at org.eclipse.jface.viewers.TreeViewer.replace(TreeViewer.java:490) 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.access$0(TreeModelContentProvider.java:524) 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)
>How many threads do you have? Approx 200-300
Pls also note that I am on Version: 2020-12 (4.18) Build id: I20200922-1800 i.e. 4.18 (Integration Builds)
(In reply to Clemens Wyss from comment #6) > Pls also note that I am on > Version: 2020-12 (4.18) > Build id: I20200922-1800 > > i.e. 4.18 (Integration Builds) Means: you see regression compared with 4.17? (In reply to Clemens Wyss from comment #5) > Approx 200-300 Are they all short living, so that they are starting and disappearing very, for a longer period of time? Any chance to have an reproducer?
>Means: you see regression compared with 4.17? not sure. Just went back to Version: 2020-09 (4.17) Build id: I20200902-1800 and facing the same issue. With 4.17 I have been on integration builds, too. Pretty sure that a month ago this problem was not present. >Are they all short living, so that they are starting and disappearing very, >for a longer period of time? the mentioned 200-300 are more or less "static" (but many of em mostly idle). Other threads may come and go. AND in some threads we change the threads name while running >Any chance to have an reproducer? Unfortunately not, sorry. I know, this doesn't help solving/analyzing the "problem" The (Thomcat run) App I am working on is absolutely responsive when Eclipse "freezes"
(In reply to Clemens Wyss from comment #8) > >Means: you see regression compared with 4.17? > not sure. Just went back to > > Version: 2020-09 (4.17) > Build id: I20200902-1800 > > and facing the same issue. Thanks. > With 4.17 I have been on integration builds, too. > Pretty sure that a month ago this problem was not present. That couldn't be a change in your code may be? Would be great if you could bisect in which build you see the problem appearing, even if you could just identify that it was something like "afeter 4.17 M3".
Due to this issue/bug in Eclipse I have found an issue in our code. From time to time we did effectively spawn "insanely many" (due to VisualVM approx 400!) threads just to do something "asynchronously". Could "fix" this by making use of an (single threaded and debouncing) executorService. >That couldn't be a change in your code may be? The code I "fixed" is very old. It may be due to the "data" that there were/are more invokations and hence thread-spawns... Now to me "this issue" is "solved". BUT the question remains why Eclipse JDT has a problem with "insanely/stupidly many threads being spawned 'concurrently'" whereas e.g. VisualVM doesn't. Maybe improve the refresh-debouncing algorithm?
@Andrey : thx a lot (vielen Dank) for looking into this Let me know if I can help any further. For example testing an improved "refresh-debouncing algorithm". Which I can/could easily by reverting my "change"/"improvement" ;)
One point: could you please open Debug view and post here, which options are checked and which not under view menu -> Java -> ...
[x]Show Monitors [x]Show Running Threads [ ] Show System Threads [ ] Show Qualified Names [ ] Show Thread Groups
I'm facing the same issue with 4.16. My application has ~350 more or less idle threads. Eclipse hangs horrible for a couple of seconds once I enter a new method/stack before I can step over without further freezes. Once I enter a new method/stack the freeze fun starts over again. org.eclipse.swt.internal.win32.OS.SendMessage(Native Method) org.eclipse.swt.widgets.Tree.getSelection(Tree.java:3387) org.eclipse.swt.widgets.Tree.getSelection(Tree.java:3407) org.eclipse.swt.widgets.Tree.getSelection(Tree.java:3407) org.eclipse.swt.widgets.Tree.getSelection(Tree.java:3457) org.eclipse.jface.viewers.TreeViewer.getSelection(TreeViewer.java:231) org.eclipse.jface.viewers.TreeViewer.setSelection(TreeViewer.java:308) org.eclipse.jface.viewers.AbstractTreeViewer.setSelectionToWidget(AbstractTreeViewer.java:2564) org.eclipse.jface.viewers.AbstractTreeViewer.setSelectionToWidget(AbstractTreeViewer.java:3020) org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1407) org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:363) org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1361) org.eclipse.jface.viewers.TreeViewer.setChildCount(TreeViewer.java:384) org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.handleAdd(TreeModelContentProvider.java:1343) org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateNodes(TreeModelContentProvider.java:1263) org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateNodes(TreeModelContentProvider.java:1299) org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateNodes(TreeModelContentProvider.java:1299) org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateNodes(TreeModelContentProvider.java:1299) org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateModel(TreeModelContentProvider.java:563) org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.doModelChanged(TreeModelContentProvider.java:530) org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.access$0(TreeModelContentProvider.java:524) org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider$DelayedDoModelChangedJob.runInUIThread(TreeModelContentProvider.java:436) org.eclipse.ui.progress.UIJob.lambda$0(UIJob.java:95) org.eclipse.ui.progress.UIJob$$Lambda$730/0x00000008015ad440.run(Unknown Source) org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40) org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185) - locked org.eclipse.swt.widgets.RunnableLock@2fe9cb7a org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4005) org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3633) org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1158) org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1047) org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155) org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:658) org.eclipse.ui.internal.Workbench$$Lambda$128/0x0000000800e33c40.run(Unknown Source) org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:557) org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:154) org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:150) org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:137) org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:107) org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401) org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:564) org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:657) org.eclipse.equinox.launcher.Main.basicRun(Main.java:594) org.eclipse.equinox.launcher.Main.run(Main.java:1447)
(In reply to Markus S from comment #14) > I'm facing the same issue with 4.16. > My application has ~350 more or less idle threads. > > Eclipse hangs horrible for a couple of seconds once I enter a new > method/stack before I can step over without further freezes. Once I enter a > new method/stack the freeze fun starts over again. > > Can you try to start Eclipse with the system property -Dorg.eclipse.jdt.internal.debug.core.model.ThreadNameChangeListener.disable
Thanks, but tetting that property did not have any effect.
I was trying to check the behavior with 4.19 but I'm unable to start my application with 4.19 anymore (see bug 574031)
Markus, do you jave a chance to debug your application on Linux platform? Just wondering if we see some weird Windows/SWT tree selection issue on big trees. How many threads do you see im the Debug view before the freeze? Are there many short living threads (starting/terminating all the time)?
Unfortunately my application consists of 750 bundles worth several GB so it's not that easy to setup a Linux VM and try to reproduce the problem in the VM. Also not sure if running it in a VM would help at all. After startup, my application has a constant level of roughly 350 threads, there are lots of thread pools containing demons and workers. There are no short living threads since we pre-start all necessary threads and keep them idle/park. Every time I enter a specific stack frame, it takes a couple of seconds before it "stabilizes". Also what I noticed that if set a breakpoint in parts of the code that multiple threads are hitting at the same time the problem gets much worse and Eclipse freezes multiple times, resumes for a bit, freezes again, while you can see the debug view slowly expanding the stack frames on each thread.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
