debug: make allThreadStop reason generic

[paul-marechal]

What it does

When we receive a stopped event from a debug adapter, a
allThreadStopped flag can be set. When doing so, it feels weird to
display the reason of the thread that caused it on other threads.

This commit reports "PAUSED" for all the paused threads, but keeps
displaying the reason for the thread that caused the event.

How to test

Run a multi-threaded debug session that pauses every thread when one hit a breakpoint hit. The latter should be stopped with reason "PAUSED ON BREAKPOINT", while all the others threads should just display "PAUSED".

I used the following vscode extension and workspace (linux/mac? only)

• cdt-gdb-vscode-0.0.90.vsix.zip
• cpp-threading.zip

Run the task "Build C++", then you should be able to debug using the "Debug C++" configuration. Place a breakpoint on line 6 to break inside a function that runs in a separate thread.

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[paul-marechal]

This PR aligns Theia's UI with VS Code.

[akosyakov]

Run a multi-threaded debug session that pauses every thread when one hit a breakpoint hit. The latter should be stopped with reason "PAUSED ON BREAKPOINT", while all the others threads should just display "PAUSED".

Please elaborate how with which extension which setup.

[paul-marechal]

@akosyakov updated

[akosyakov]

code-wise it makes sense to me

[marcdumais-work]

Hi @marechal-p ,

I noticed something that seems wrong. The thread that hits the breakppoint is ok, but the other ones, though shown as "Paused" do not allow getting stack and variable info: "Not paused".

[marcdumais-work]

Here's the same scenario, on master:

Ideally we would not have to click "load more frames", but otherwise it works well.

[marcdumais-work]

I tested debugging Java with a small multi-threaded program and did not notice any problems vs master.

[paul-marechal]

I will investigate this call stack issue a bit more before thinking about merging.

[marcdumais-work]

@marechal-p As you mentioned offline, when debugging C/C++ on theia master, the stack frames fetched are bogus - they are a copy of the stack frames of the thread that stopped on the breakpoint, not of the selected thread.

So the issue I found above may not be as bad as I initially thought.

[paul-marechal]

@marcdumais-work the C++ debug adapter I have been using is not really good at fetching stack frames for threads paused with the allThreadStopped flag. If you can check again with your Java setup that we don't get regressions, then feel free to merge :)

[marcdumais-work]

@marcdumais-work the C++ debug adapter I have been using is not really good at fetching stack frames for threads paused with the allThreadStopped flag. If you can check again with your Java setup that we don't get regressions, then feel free to merge :)

Ok, let me check with the latest version of this PR.

[marcdumais-work]

Ok, let me check with the latest version of this PR.

@marechal-p Java debugging is still good with latest version of this PR 👍