envFile is not accepted in launch configuration in Linux/WSL

[mcrumiller]

OS: Windows 11 / WSL
VSCode version: 1.80.1
CodeLLDB version: v1.9.2`
Compiler: N/A
Debuggee: N/A

When VSCode is open in Windows, I can use env adn envFile in my launch.json just fine. When I open VSCode and attach to WSL, however, I cannot use either:

[vadimcn]

You are missing "type": "lldb".

[mcrumiller]

@vadimcn it's not missing, it was simply covered up by the hover text. I've moved it to the top so you can see the full thing:

[vadimcn]

env doesn't make sense for "attach" requests - you can't change the environment of an already running process.

[mcrumiller]

Hmm ok. I was hoping to read in an env var from a file using envFile and use that variable in the configuration.

[mcrumiller]

With that in mind, I think envFile makes sense but env does not, correct?

[vadimcn]

I was hoping to read in an env var from a file using envFile and use that variable in the configuration.

If you want to use expand an environment variable into the launch configuration, you can use this syntax: ${env:NAME}

[mcrumiller]

Right, but I'm unable to use environmental variables stored in a file because envFile does not appear to be working.

[mcrumiller]

Sorry, I'll update the issue name. My primary issue is this: I have a python debugging instance that I need to attach the rust LLDB debugger to. I need to send the process ID to the launch configuration. I'm currently doing it using an extra extension that parses the pID from a shell command, but this requires a 3rd-party requirement that I'd like to remove from the process (the shell command extension).

I'm instead writing the pID to an environmental variable file, which I'd like the LLDB launch configuration to read from, but the envFile appears not to work on Linux, although it does just fine in Windows.

[vadimcn]

envFile is read to set up the environment of the newly launched processes, just like env. It does not participate in launch.json expansion (which, btw, is done by VSCode, not by the extension).

I suppose you could create a custom launch configuration and use Python script(s) to read pid from a file and then use it to attach.

[mcrumiller]

@vadimcn right--I would like the LLDB launch configuration to be able to read an environmental variable from a file so that it's used when launching the LLDB process. According to #866, this was implemented in 1.9.1, but it appears to have only been implemented for Windows and doesn't work in Linux, unless I'm doing something wrong.

Thank you for the link to custom launches, I will look into that.

[vadimcn]

it appears to have only been implemented for Windows and doesn't work in Linux, unless I'm doing something wrong.

It was never meant to make envFile entries to be available for expansion into launch.json. What you describe shouldn't be possible... unless VSCode somehow reads it for you.

[mcrumiller]

Hi @vadimcn, are you willing to help me a bit? I'm attempting go the custom launch route but having a bit of trouble. This is a joint Python+Rust process. I've managed to get LLDB to attach within VSCode to the process (so I know that it works), but it requires some manual work and I'm trying to automate the process.

Here are my steps:

1. Launch a Python debugging session in VS Code.

2. Get the process ID, say it's currently 5911.

3. From an external console, run the following:

   code --open-url "vscode://vadimcn.vscode-lldb/launch/config?{'request':'attach','pid':5911,'sourceLanguages':'rust'}"

   but I get the following error:

   Unable to connect to VS Code server: Error in request.
   Error: connect ENOENT /mnt/wslg/runtime-dir/vscode-ipc-a020798e-fa0b-434e-8705-006478f909d9.sock
       at PipeConnectWrap.afterConnect [as oncomplete] (node:net:1247:16) {
     errno: -2,
     code: 'ENOENT',
     syscall: 'connect',
     address: '/mnt/wslg/runtime-dir/vscode-ipc-a020798e-fa0b-434e-8705-006478f909d9.sock'
   }
   

I'm having a bit of trouble disagnosing here. Is my url malformed?

Thank you!!

[mcrumiller]

Ok, this was a WSL issue and involved the vscode server cache not being invalidated: microsoft/vscode-remote-release#6997. I've made a little progress, I'll look into this some more.