microsoft / microsoft/vscode-cpptools

Environment variables disappear when the program forks when debugging a C++ program

Open
#13,051 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

debugger help wanted
Dominant language
TypeScript
Stars
6.2k
Forks
1.7k
Avg merge
14h 46m
Merged PRs (30d)
61

Description

Environment
Bug Summary and Steps to Reproduce

Bug Summary: Environment variables disappear when the program forks when debugging a C++ program

VScode gets rid of environment variables when I debug a C++ programs which forks.

Here is an example with a 2 files project :

hello1.cpp

#include <boost/process.hpp>


namespace ps = boost::process;

int main() {
  std::string command = "/home/user/MyProject/hello2";
  ps::child c(command);

  c.wait();

  return 0;
}

hello2.cpp

#include <iostream>


int main() {
  std::cout << "Hello world" << std::endl;

  const char* myVarEnv = std::getenv("FOO");
  std::cout << "myVarEnv = " << myVarEnv << std::endl;

  return 0;
}

to build hello1.cpp and hello2.cpp :

g++ -g hello1.cpp -o hello1 -lpthread
g++ -g hello2.cpp -o hello2

What is astonishing is when I debug hello1 I can see my FOO environment variable is correctly defined :

-exec show environment FOO
FOO = foo

Then I switch the follow-fork-mode to child :

-exec set follow-fork-mode child

But when I fork in hello2, gdb can't find the FOO environment variable anymore :

-exec show environment FOO
Environment variable "FOO" not defined.

but oddly enough, the program hello2 manages to print the environment variable correctly :

myVarEnv = foo

Moreover, if I debug this program with gdb, gdb can find the FOO environment variable perfectly in both hello1 and hello2 :

(gdb) show environment FOO     
FOO = foo

Since, VScode just uses gdb, that means VScode should be able to find the FOO environment normally, right ?

Debugger Configurations
{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "name": "(gdb) Launch",
      "type": "cppdbg",
      "request": "launch",
      "program": "/home/user/MyProject/hello1",
      "args": [],
      "stopAtEntry": false,
      "cwd": "${fileDirname}",
      "environment": [
        {"name": "FOO", "value": "foo"}
      ],
      "externalConsole": false,
      "MIMode": "gdb",
      "setupCommands": [
          {
              "description": "Enable pretty-printing for gdb",
              "text": "-enable-pretty-printing",
              "ignoreFailures": true
          },
          {
              "description": "Set Disassembly Flavor to Intel",
              "text": "-gdb-set disassembly-flavor intel",
              "ignoreFailures": true
          }
      ]
    }
  ]
}
Debugger Logs
Hello world
myVarEnv = foo
[1] + Done
Other Extensions

No response

Additional Information

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the issue with hello1.cpp and hello2.cpp, the launch configuration, and GDB's follow-fork-mode set to child. Compare show environment FOO before and after the fork while confirming the child still prints FOO; done means the debugger reports the variable in both processes as standalone GDB does.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp, typescript, vscode
Domain
devtools
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.