Bug 553196 - Toolbar & console terminate buttons always enabled even when the DSPDebugTarget is terminated
Summary: Toolbar & console terminate buttons always enabled even when the DSPDebugTarg...
Status: RESOLVED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: LSP4E (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Pierre-Yves Bigourdan CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-18 17:10 EST by Pierre-Yves Bigourdan CLA
Modified: 2022-02-04 09:12 EST (History)
3 users (show)

See Also:


Attachments
terminate always enabled (14.64 KB, image/png)
2019-11-18 17:10 EST, Pierre-Yves Bigourdan CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre-Yves Bigourdan CLA 2019-11-18 17:10:23 EST
Created attachment 280685 [details]
terminate always enabled

This seems due to the fact that canTerminate always returns true, therefore the button is always enabled (https://git.eclipse.org/c/lsp4e/lsp4e.git/tree/org.eclipse.lsp4e.debug/src/org/eclipse/lsp4e/debug/debugmodel/DSPDebugTarget.java#n315). Will be submitting a patch shortly.
Comment 1 Eclipse Genie CLA 2019-11-18 17:17:43 EST
New Gerrit change created: https://git.eclipse.org/r/152908
Comment 2 Pierre-Yves Bigourdan CLA 2019-11-18 17:56:33 EST
Note that the provided patch only fixes the toolbar button. The "Terminate" button in the Console View always stays enabled, on my machine at least.

One would hope that my patch would disable both buttons. Indeed, the canTerminate method in the DSPProcess, which is called by the Console View to handle the state of the button, simply delegates to the DSPDebugTarget's revised implementation: https://git.eclipse.org/c/lsp4e/lsp4e.git/tree/org.eclipse.lsp4e.debug/src/org/eclipse/lsp4e/debug/console/DSPProcess.java#n37).

However, there seems to be a race condition. The canTerminate from the DSPProcess is called slightly before we get the TerminatedEvent from the debug adapter (this event sets the fTerminated boolean to true in the DSPDebugTarget). If I put a short sleep in DSPProcess.canTerminate, the debug adapter message comes in first, changing fTerminated to false and consequently DSPProcess.canTerminate will return false when it finishes sleeping. The button is then successfully disabled.

Not sure how to fix this other problem though, as I can't control when the UI thread tries to see if it can disable the button in the Console View. Ideas welcome. :)
Comment 4 Pierre-Yves Bigourdan CLA 2019-11-19 02:45:10 EST
Any ideas on the Console View button Mickael (see my second message)?
Comment 5 Mickael Istria CLA 2019-11-20 02:16:32 EST
(In reply to Pierre-Yves B. from comment #4)
> Any ideas on the Console View button Mickael (see my second message)?

Not really.
I think the console isn't attached to the debug target, but to the IProcess, so maybe it means that DSPProcess is to be improved similarly to what you did for DSPDebugTarget?
Comment 6 Pierre-Yves Bigourdan CLA 2019-11-20 17:06:31 EST
(In reply to Mickael Istria from comment #5)
> I think the console isn't attached to the debug target, but to the IProcess

Yep, we both agree on this.

> so maybe it means that DSPProcess is to be improved similarly to what you
> did for DSPDebugTarget?

As lsp4e doesn't directly control the state of the button in the Console view and we're facing a race condition (i.e. the correctly implemented DSPProcess.canTerminate is called a bit too early), I don't think there's any easy fix that can be done. However, I found a similar bug at the Platform level, Bug 497632. Will follow up on that one.
Comment 7 Sarika Sinha CLA 2019-11-20 21:55:50 EST
(In reply to Mickael Istria from comment #5)
> (In reply to Pierre-Yves B. from comment #4)
> > Any ideas on the Console View button Mickael (see my second message)?
> 
> Not really.
> I think the console isn't attached to the debug target, but to the IProcess,
> so maybe it means that DSPProcess is to be improved similarly to what you
> did for DSPDebugTarget?

There is a difference between Run/Debug.
During Run-> only attached to IProcess
During Debug-> Debug Target drives the termination which destroys the process
Comment 8 Paul Pazderski CLA 2019-11-21 10:27:58 EST
(In reply to Mickael Istria from comment #5)
> I think the console isn't attached to the debug target, but to the IProcess,

Yes. And the consoles termination button state is once updated on creation (and this could happen rather late because creation is asynchronous) and for each debug event with the process as source.
The often used RuntimeProcess send such a notification once the OS process died which disables the button (see RuntimeProcess#fireTerminateEvent).

This also updates the console label which usually shows '<terminated>' at the beginning but does not for DSPProcess.

So sending a terminate debug event for the DSPProcess should be enough to fix the console button problem.
Comment 9 Eclipse Genie CLA 2019-11-21 15:54:29 EST
New Gerrit change created: https://git.eclipse.org/r/153147
Comment 10 Pierre-Yves Bigourdan CLA 2019-11-21 15:56:51 EST
(In reply to Paul Pazderski from comment #8)
> (In reply to Mickael Istria from comment #5)
> > I think the console isn't attached to the debug target, but to the IProcess,
> 
> Yes. And the consoles termination button state is once updated on creation
> (and this could happen rather late because creation is asynchronous) and for
> each debug event with the process as source.
> The often used RuntimeProcess send such a notification once the OS process
> died which disables the button (see RuntimeProcess#fireTerminateEvent).
> 
> This also updates the console label which usually shows '<terminated>' at
> the beginning but does not for DSPProcess.
> 
> So sending a terminate debug event for the DSPProcess should be enough to
> fix the console button problem.

Thanks for the insight! I was seeing the button updates for other events, but we weren't notifying the DSPProcess about the final termination. I've just uploaded a patch that fixes the problem.