Repository navigation
Core dump debugging performance too slow #12772
Description
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!)
Activity
borjamunozf commentedon Sep 26, 2024
I have a dummy python script to calculate elapsed time and map the IDs of the request. It shows the top 10.
However, something it's be wrong because the total elapsed time is way too high always, not the real one. Probably the conc requests and so on, but at least it's helpful to get the longest requests...?
For the gdb_multiarch txt:
The 1100 takes ~16 minutes itself, which maps to this request (var-create cutFrames)
The 1007 request is file-exec-and-symbols, took ~1min 30secs
Could be this issue linked to #9988 ?