Core dump debugging performance too slow

Environment

• OS and version: Windows 11
• VS Code: 1.93.1
• C/C++ extension: v1.22.6 (pre-release), v1.21.6
• OS and version of remote machine (if applicable): WSL 2.2.4 - Ubuntu 22
• GDB / LLDB version: 15.1, 12.1 multiarch, 7.1

Bug Summary and Steps to Reproduce

Bug Summary:

Core dump debugging is quite slow with real world C++ scenarios. Last sample data we received from other devs throws a bad performance and overall experience.

Sample measurements:

• GDB commnd line takes ~1min-30-45 secs.
• VScode C++ breakpoint stop ~9 minutes, but I have other samples taking 14 minutes or 20 minutes
• This is not specific to any laptop. Other colleagues have roughly same numbers.

From what we have seen, the symbol loading is not the main pain point, but the requests done afterwards the symbols have been loaded.

• The elapsed time for a lot ot threads takes ~17 seconds (and there's total of 64 threads)

Tested in different OS versions, VScode and C++ ext. I don't think it's an issue or regression because this performance problems with debugging production C++ projects has been not new since a few years at least when I started working with vscode.

I also tested with different gdb versions with no effect regarding perf in Vscode core dump debugging:

• gdb-multiarch v12.1
• gdb 15.1 (latest release). I built this as I could from source, but I see some error logs in the debug console that could impact...

Debugger Configurations

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "(gdb) Launch Core Dump",
      "type": "cppdbg",
      "request": "launch",
      "program": "/mnt/disk1/asd/app/bin/DispApp",
      "args": ["-g "],
      "stopAtEntry": false,
      "coreDumpPath": "${workspaceFolder}/coreDump",
      "sourceFileMap": {
          "/asdshell": "${workspaceFolder}"
      },
      "additionalSOLibSearchPath": "/mnt/disk1/asd/app/lib;/opt/sdks/whatever-1.1.0/x86/sysroots/x86-what-linux-dev/lib/.debug;/opt/sdks/whatever-1.1.0/x86/sysroots/x86-what-linux/usr/lib",
      "cwd": "${workspaceFolder}",
      "miDebuggerPath": "/usr/bin/gdb-multiarch",
      "MIMode": "gdb",
      "logging": {
        "engineLogging":"verbose",
        "trace": true,
        "traceResponse": true
      },
     "setupCommands": [
      {
        "description": "set sysroot",
        "text": "-gdb-set sysroot ${input:sdkSysPath}/sysroots/x86-what-linux/",
        "ignoreFailures": false
      },
        {
          "text": "-gdb-set auto-load safe-path /",
          "description": "enable safe path",
          "ignoreFailures": false
        }
      ]
    }
  ],
  "inputs": [
    {
      "id": "sdkSysPath",
      "type": "command",
      "command": "shellCommand.execute",
      "args": {
        "command": "ls -d -1 /opt/sdks/*/*",
        "useSingleResult": true
      }
    }
  ]
}

Debugger Logs

Providing logs in .txt because too long for 15.1, 12.1..

Other Extensions

No response

Additional Information

Log file (too huge for pasting)
coredump_issue_debug_vscodelog_15.txt

gdb-multiarch 12.1 (20 minutes!)

gdb_multiarch_12.1_20minutes.txt

gdb15_fresh_wsl(1).txt

Reproduce the core-dump session using the supplied launch configuration, then inspect the attached debugger logs for the repeated requests after symbol loading. Compare the timings across the GDB 7.1, 12.1, and 15.1 samples; done should identify the limiting operation and provide a verified performance improvement for the reported multi-threaded cases.