[bug] `cppdbg` hangs up and quits out by itself

[ClSlaid]

Bug type: Debugger

Describe the bug

• OS and Version: Windows 11 home 21H1 22000.556
• VS Code Version:

  Version: 1.65.2 (system setup)
  Commit: c722ca6c7eed3d7987c0d5c3df5c45f6b15e77d1
  Date: 2022-03-10T14:33:55.248Z
  Electron: 13.5.2
  Chromium: 91.0.4472.164
  Node.js: 14.16.0
  V8: 9.1.269.39-electron.0
  OS: Windows_NT x64 10.0.22000
  

• C/C++ Extension Version: v1.9.7
• Other extensions you installed (and if the issue persists after disabling them):

  Name: C/C++ Extension Pack
  ID: ms-vscode.cpptools-extension-pack
  About: Popular extensions for C++ development in Visual Studio Code.
  Version: 1.1.0
  Distributor: Microsoft
  VS Marketplace link: https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools-extension-pack
  
  Simplified Chinese Extension
  Golang
  Rust-Analyzer
  

• A clear and concise description of what the bug is.
  Start debugging, command-line showes, with input blocked:

  & 'c:\Users\<user>\.vscode\extensions\ms-vscode.cpptools-1.9.7\debugAdapters\bin\WindowsDebugLauncher.exe' '--stdin=Microsoft-MIEngine-In-30v2n0bd.4ez' '--stdout=Microsoft-MIEngine-Out-sulr42l3.5u3' '--stderr=Microsoft-MIEngine-Error-42mhsbwh.w3f' '--pid=Microsoft-MIEngine-Pid-htnzwcvq.dhz' '--dbgExe=C:\msys64\usr\bin\gdb.exe' '--interpreter=mi'

By this time, inputting in the terminal is impossible, and no break points from the source file could be hitten, even if you compiled a single file with -g option.
Wait for a little more time, the debugger will quit out by itself, though the program requires input from stdin.
Detailed information is in the video below:

2022-03-26.01-39-50_Trim.mp4

To Reproduce
Please include a code sample and launch.json configuration.

// launch.json
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "C++ quick run",
      "type": "cppdbg",
      "request": "launch",
      "program": "${workspaceFolder}/${fileBasenameNoExtension}.exe",
      "args": [],
      "MIMode": "gdb",
      "miDebuggerPath": "C:\\msys64\\usr\\bin\\gdb.exe",
      "stopAtEntry": false,
      "cwd": "${workspaceFolder}",
      // "console": "integratedTerminal",
      "preLaunchTask": "C/C++: g++.exe produce active file",
      "setupCommands": [
        {
          "description": "Enable pretty-printing for gdb",
          "text": "-enable-pretty-printing",
          "ignoreFailures": true
        }
      ],
      "logging": {
        "engineLogging": true,
        "trace": true,
        "traceResponse": true
      }
    }
  ]
}

// task involved
{
      "type": "cppbuild",
      "label": "C/C++: g++.exe produce active file",
      "command": "C:\\msys64\\usr\\bin\\g++.exe",
      "args": [
        "-g",
        "--std=c++17",
        "-fdiagnostics-color=always",
        "-o",
        "${fileDirname}\\${fileBasenameNoExtension}.exe",
        "${file}"
      ],
      "options": {
        "cwd": "${fileDirname}"
      },
      "problemMatcher": ["$gcc"],
      "group": "build",
      "detail": "produced by debugger" // cpptools
    },

Steps to reproduce the behaviour:

1. Go to the single file you want to run
2. Click on debug "C++ quick run".
3. Wait for it.
4. See the error.

Additional context
If applicable, please include logging by adding "logging": { "engineLogging": true, "trace": true, "traceResponse": true } in your launch.json

Before raising this issue, I've found that there are issues about Windows10's Beta UTF-8 feature, but I've turned it on and off, and nothing had happened, the bug now still exists.
Here is the log file, it's very huge and some part of it is in Chinese.

[WardenGnaw]

For some reason, GDB is unable to find the source file to the binary you are launching.

1: (2015) <-1014-break-insert -f foo.cpp:8
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (2030) ->&\"No source file named foo.cpp.\\n\"\r\n"},"seq":292}
1: (2030) ->&"No source file named foo.cpp.\n"

Is it possible that the binary that is actually running is from main.cpp?

Can you try enabling: "stopAtEntry": true?

[ClSlaid]

No, when debugging foo.cpp with the file compiled from main.cpp (main.exe) removed, the debugger still shows the same behaviour.

And the same log as "No source file named foo.cpp.\n" showed up, with the main thread showing unknown source (I stopped it at the entry).

I've tried debugging golang with the dlv plugin, and it worked well. So it is exactly a cpptool bug.

[ClSlaid]

For some reason, GDB is unable to find the source file to the binary you are launching.

1: (2015) <-1014-break-insert -f foo.cpp:8
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (2030) ->&\"No source file named foo.cpp.\\n\"\r\n"},"seq":292}
1: (2030) ->&"No source file named foo.cpp.\n"

Is it possible that the binary that is actually running is from main.cpp?

Can you try enabling: "stopAtEntry": true?

This might be a similar issue to #1546.

However, I did set up and change my VSCode version to insiders along with adding sourceFileMap in launch.json, yet I still get such a problem.