Running the memoryinspector in WSL

[jlonnberg]

Description The extensions fails to activate properly when running in WSL

How to reproduce: Launch a simple gcc project in WSL and try to use the extension

Expected behavior The extension is activated properly in WSL

Environment

• OS: WSL, Ubuntu 22.04 on windows 11
• Browser:
• Theia or VS Code Version:

Additional information

[thegecko]

Thanks for raising this issue. The behaviour seen here is due to a culmination of a few things:

• VS Code has multiple runtime environments or extension hosts and in some setups, the workspace host is separated from the UI host. This is the case with VS Code remote, WSL and codespaces
• Debuggers have to run in one of these hosts and each host isn't aware of debug sessions running in other hosts
• This extension has to run in the same host as the debugger in order to interact with it

The host an extension runs in is outlined using the extensionKind package.json entry and we currently have this set to ui for the following reasons:

• It works in the normal desktop version of VS Code (as would workspace TBF)
• Arm have a unique use case where we run a debugger in the UI extension host to enable browser-based debugging of physical hardware from an online IDE (e.g. Keil Studio Cloud)

However this setup means the memory inspector extension doesn't see any debuggers running in remote hosts.

In order to resolve this issue, we need to decide where we want this extension to run. The options boil down to:

1. Keep the existing setup. Desktop and browser debug will continue to work, but remote debug scenarios wont be supported.
2. Change this to run in the workspace. Desktop and remote scenarios will work, but browser debugging will not.

I will separately raise a question with the VS Code team to get their input.

As this is an OSS project and the UI use case may be unique to Arm, I suggest we go with option 2 and change the default behaviour to support remote workspaces. Arm then need to investigate a workaround for our browser scenario.

Feedback welcome @jreineckearm

[jlonnberg]

@thegecko There's also the option to list the extension as UI preferred and workspace as secondary option. This did the trick for us when trying to figure out what the problem was

[thegecko]

@thegecko There's also the option to list the extension as UI preferred and workspace as secondary option. This did the trick for us when trying to figure out what the problem was

Hmm, my tests in that scenario didn't work. But if it did, it would still break the browser scenario :( In order for this to continue to work in a serverless environment (vscode.dev) it would still need ui in the list somewhere.

Would you mind confirming if this fixes your setup:

...
"extensionKind": [
  "ui",
  "workspace"
]
...

[jlonnberg]

@thegecko Yes, that solved the problem for us at least

[colin-grant-work]

But if it did, it would still break the browser scenario :(

Our experience is also that you basically have to commit to one extension host or the other when working remotely. The Memory Inspector will only run in one extension host, and that needs to be the one that runs the debugger. If you had different debuggers running in the different hosts, only one would work with the Memory Inspector. For our use cases we prefer the workspace extension host, so we've just modified the package.json accordingly, but it's an unfortunate limitation.

[thegecko]

Changed in #151

[thegecko]

Hmm, my tests in that scenario didn't work... ...Yes, that solved the problem for us at least

Forgot to mention, I confirmed the PR linked above does indeed fix WSL support in my test setup