Community
Participate
Working Groups
Created attachment 285056 [details] state after process was terminated on breakpoint Put a line breakpoint at "You can't stop me" line. Start debugger with code below. Wait until it stops at breakpoint. Now hit the "Terminate" button. The "Terminate" debugger button stays (forever) enabled, but it should be disabled after the process was terminated. If we simply let the process continue, the button is properly shown as disabled after process termination. See attached screenshot. public class Unstoppable { public static void main(String[] args) { System.out.println("You can't stop me!"); } } It is a regression in 4.18.
This is a regression from bug 567345 change https://git.eclipse.org/r/c/platform/eclipse.platform.debug/+/170009. Reverting this patch fixes terminate status.
@Hannes, Can you work on this?
Yes, I can work on it. But unfortunately I cannot reproduce this issue. I tested it with the latest (not released) version of Eclipse IDE for Eclipse Committers provided by the Oomph installer. The about tab says, Version: 2020-12 (4.18.0), Build id: 20201210-1552. From that I also launched the org.eclipse.platform.ide product where only the org.eclipse.debug.core and org.eclipse.debug.ui are taken from the workspace, the rest comes from the Target-Platform, which is the running platform. Both work fine for me. If I debug your example Java application it stops at the break-point. And when I hit the terminate button (in the toolbar or the console) the debugged JVM fully terminates and the terminate button is disabled (in the toolbar and the console). Also I'm not sure where exactly the state of the termination button is changed. What I found so far are the org.eclipse.debug.internal.ui.commands.actions.TerminateCommandAction org.eclipse.debug.internal.core.commands.TerminateCommand I first thought the terminate button is disabled once TerminateCommandAction.isExecutable(Object) returns false but it seems to be disabled earlier. Even before the TerminateCommand is executed and the 'VirtualMachine' of org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget has exited.
(In reply to Hannes Wellmann from comment #3) > Yes, I can work on it. > > But unfortunately I cannot reproduce this issue. > I tested it with the latest (not released) version of Eclipse IDE for > Eclipse Committers provided by the Oomph installer. The about tab says, > Version: 2020-12 (4.18.0), Build id: 20201210-1552. > From that I also launched the org.eclipse.platform.ide product where only > the org.eclipse.debug.core and org.eclipse.debug.ui are taken from the > workspace, the rest comes from the Target-Platform, which is the running > platform. > > Both work fine for me. What is interesting, I can observe the problem in my 4.19 main workspace (SDK + few extra plugins + yourkit + egit etc), but today I can't reproduce it in Eclipse started from this workspace. So I can't explain what is changed now and how I've managed to bisect it yesterday (see comment 1). Today it doesn't matter which commit I have in platform debug, it just works. I also can reproduce the bug with plain 4.18 SDK that has nothing else installed. 4.17 SDK is fine. So may be that is something timing related (yesterday I was running heavy application tests in background). Doesn't explain however why it is always broken in plain 4.18 SDK. Simeon: can *you* reproduce this?
So what I did now is to download latest nightly SDK build from here: https://download.eclipse.org/eclipse/downloads/drops4/I20201216-2110/ Extract, run with a new workspace, paste the snipped into Package Explorer, create breakpoint, debug, terminate => broken. From the same workspace, create new Eclipse launch config, debug, paste there same snippet, create breakpoint, debug, terminate => broken. Same result with official 4.18 SDK. So whatever is in my personal SDK workspace (I have most of SDK projects checked out) or additionally installed plugins in the target platform prevents me from reproducing this *from inside* debugger. I'm using OpenmJDK 11.0.8 if that matters.
(In reply to Andrey Loskutov from comment #5) > So what I did now is to download latest nightly SDK build from here: > https://download.eclipse.org/eclipse/downloads/drops4/I20201216-2110/ > > Extract, run with a new workspace, paste the snipped into Package Explorer, > create breakpoint, debug, terminate => broken. > > From the same workspace, create new Eclipse launch config, debug, paste > there same snippet, create breakpoint, debug, terminate => broken. > > Same result with official 4.18 SDK. All three cases work for me without error. (Windows 10 + OpenJDK 11/12/15)
Could not reproduce with 20201216-2110 on main or child eclipse on Mac.
@Vikas, Can you reproduce on linux?
(In reply to Sarika Sinha from comment #8) > @Vikas, > Can you reproduce on linux? Yes, The problem exist on RHEL !
(In reply to Andrey Loskutov from comment #5) > So what I did now is to download latest nightly SDK build from here: > https://download.eclipse.org/eclipse/downloads/drops4/I20201216-2110/ > > Extract, run with a new workspace, paste the snipped into Package Explorer, > create breakpoint, debug, terminate => broken. > > From the same workspace, create new Eclipse launch config, debug, paste > there same snippet, create breakpoint, debug, terminate => broken. > > Same result with official 4.18 SDK. > > So whatever is in my personal SDK workspace (I have most of SDK projects > checked out) or additionally installed plugins in the target platform > prevents me from reproducing this *from inside* debugger. > > I'm using OpenmJDK 11.0.8 if that matters. I tried exactly what you described, but don't get any of the faulty behaviour. I'm using Win10 + GraalVM CE 20.2. I'll later try it on Linux (Debian 10), hopefully I get the errors there. @Andrey What OS do you use? I'm not yet familiar with the corresponding code, but for me it looks like that the terminate button becomes disabled at the end of TerminateCommandAction.run() (defined in DebugCommandAction), when setEnabled() is called (usually with argument false). This should call setEnabled(false) to the associated Action (fAction), which causes a notifcation via firePropertyChange() on that the button's PluginActionCoolBarContributionItems are disabled too. The method TerminateCommand.isExecutable() is mainly used, when a JVM is started and the button becomes enabled.
(In reply to Hannes Wellmann from comment #10) > > @Andrey What OS do you use? RHEL 7.4 (should be almost same as CentOS 7.4). uname -a Linux socbm599 3.10.0-862.3.2.el7.x86_64 #1 SMP Tue May 15 18:22:15 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux
I can reproduce this as described by the reporter. The same behavior happens to the "Resume" button as well. If you click "Resume", it stays enabled even when not stopped on a breakpoint. Eclipse IDE for Java Developers (includes Incubating components) Version: 2020-12 (4.18.0) Build id: 20201210-1552 OS: openSUSE 15.2
I also can reproduce the error on Debian 10 Linux. But I'm not yet certain about the cause. But to me it seems to be pretty sure, that this issue is not related to the fix of Bug 567345. When I reset the content of the Runtime class to the state before the mentioned fix, the behavior is still broken. Additionally I noticed that only the image of the terminate button remains to be the active one. The toolbar-button itself is disabled (I can't click it). Furthermore if I terminate a launch with the terminate button of a console the terminate button in the main-toolbar is disabled as expected (or more precise the image becomes the disabled one) but now the console's terminate button remains to look enabled. So it seems to me, that only the toolbar-button that was clicked, remains to look active. This also fits to the behavior of the "Resume" button described by Thomas Coogan (which I can confirm). Additionally I observed the "pause" button to behave on the same way: Extend Andrey's example with an endless loop, debug it. Then pause the main-Thread. The pause button remains to look enabled (but cannot be clicked, while resume and terminate look enabled and can also be clicked). Also you don't have to hit a break-point: When you terminate a program while running (without hitting a break-point), then the terminate button remains to look active too. What's also interesting is: If your button falsely looks enabled and you switch to a perspective without the terminate button (e.g. Java) and go back into the Debug, the button looks disabled as it should (without any other action). Can anybody else using Linux can confirm what I have just described? Because of the points I described and since this issue seems to appear on Linux only, I tend to think that this is an JFace or SWT issue. Maybe the problem is in org.eclipse.jface.action.ActionContributionItem or org.eclipse.swt.widgets.ToolItem. My first idea was that it could be a problem if a toolitem is clicked and disabled in the same pass of the event-loop (respectively disabled in its selection-handler) but this seems to work in the little test-example I created. I can try to search further, but maybe someone from the JFace or SWT team has a better idea .
@Sravan, Can you comment from SWT point of view reading comment #13.
@Hannes: I'm really sorry, it happened to me to investigate another regression at same time (bug 569691) and for that, I've temporarily reverted changes on ActionContributionItem coming from bug 567905. So in the middle of bisecting debug code I've also reverted bug 567905 change, forgot about it, and continued to bisect debugger. This explains why at some point in time I was unable to reproduce the issue and assumed that were due the bug 567345. So don't try to bisect multiple regressions at same time, even if they look unrelated :-) Reverting commit 9cc8c9a465eab62070dbfa63c62337c88c501a80 (gerrit https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/170827) fixes debugger buttons for me. Since this is Linux specific, may be also caused by another bug in SWT. @Christoph: please take a look.
@Andrey just to make sure: Does this only happen on Linux and not Windows/Macos right? Then I would assume that this not a real regression, but the fix revealed an underlying problem that was there already before? I can try to take a look but fear if it only fails on linux if the active button is disabled it might be either a bug in GTK or the usage of GTK by SWT and I'm not very familiar with GTK coding yet. So if there is an GTK expert out there that could take a quick look it would be great. As it works for me in general, the problem seems to be triggered in the following case: - a button is active and hovered - user clicks the button (still hovered) what causes the button to be disabled - the buttons hot-image is still displayed, even though the button is disabled and can't be clicked - moving the mouse of the button does not change anything I would suspect from that oversavation, that when setEnabled(...) is called on a button GTK expects some call to "update button image state" or something...
Created attachment 285099 [details] Snippet to reproduce the behaviour I have created a reproducer snippet that shows the following: - If first button is clicked the image changes to the default-image (instead of the disabled one) - Second image shows the disabled as expected - Third button works as expected with dynamic updates by forcefully setting images again This shows that the change itself does only reveal an undiscovered bug in SWT-GTK backed as there is only plain SWT API is used and the change was purely about JFace. I have debugged this so far to the point that > GTK.gtk_widget_set_sensitive(topHandle, enabled); in org.eclipse.swt.widgets.ToolItem.setEnabled(boolean) is the culprit, if I just move this to the top everything works fine.
(In reply to Christoph Laeubrich from comment #16) > @Andrey just to make sure: > Does this only happen on Linux and not Windows/Macos right? Then I would > assume that this not a real regression, but the fix revealed an underlying > problem that was there already before? We are talking about regression from end user point of view. Before the change system was working fine, after the change it is broken => regression, independently how many underlying bugs were involved. > I can try to take a look but fear if it only fails on linux if the active > button is disabled it might be either a bug in GTK or the usage of GTK by > SWT and I'm not very familiar with GTK coding yet. So if there is an GTK > expert out there that could take a quick look it would be great. I would first check *what exactly* in the changed code causes the regression. > I would suspect from that oversavation, that when setEnabled(...) is called > on a button GTK expects some call to "update button image state" or > something... I haven't analysed this yet, but as I've said in previous comment, it is likely that the change uncovered existing SWT bug or may be just a different SWT behavior on GTK. Unfortunately SWT is platform dependent :-(
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/174051
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/174051 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=9f4e3a1319888ac460216bcf9402b8db421dc877
Thanks Christoph for the patch. Resolving now
@Andrey no problem, I'm glad I could help to find the right direction. And great to see, that you are about to find a solution.
*** Bug 570013 has been marked as a duplicate of this bug. ***
verified in Eclipse SDK Version: 2021-03 (4.19) Build id: I20210105-1800 OS: Linux, v.5.4.0-59-generic, x86_64 / gtk 3.24.20, WebKit 2.30.3 Java version: 11.0.9.1
*** Bug 570264 has been marked as a duplicate of this bug. ***
*** Bug 571587 has been marked as a duplicate of this bug. ***
