macos: very long wait time until applicationDidFinishLaunching is reached in VSCode but not XCode

[floooh]

Environment

• OS and version: macOS 15.2
• VS Code: 1.96.4
• C/C++ extension: 1.22.11
• GDB / LLDB version: system lldb is lldb-1600.0.39.109

Bug Summary and Steps to Reproduce

Bug Summary:

NOTE: This is not a new problem, but it seems to get worse with each new macOS version :/

When debugging a Cocoa application in VSCode with the C/C++ extension, it takes 10 seconds or so in each debug session until the applicationDidFinishLaunching callback is reached. Most of that time is spent between [NSApp run] and applicationDidFinishLaunching. This long wait time is the same between the first and followup debug sessions.

In Xcode, only the first debug session after starting Xcode shows a similar slow behaviour, while the following debug sessions start much faster (not quite instantly, but fast enough to not be an issue).

It would be good to at least investigate why there is this difference between VScode and XCode.

Steps to reproduce:

1. In Xcode, create the 'Game' builtin project, build and do some debugging. Note how everything is reasonably fast, especially in the followup debug sessions.
2. Create a launch.json in VSCode pointing to the same executable (which is a bit tricky to find: in Xcode Product => Show Build Folder in Finder to find the executable.
3. Debug the same executable in VSCode and note how very long it takes until window appears

...in VSCode, there's a metric shitton of log output on the debug console during that waiting time, all about loading symbols from system frameworks like this:

Loaded '/System/Library/PrivateFrameworks/CoreSDB.framework/Versions/A/CoreSDB'. Symbols loaded.

...maybe this symbol loading is the main reason for the long waiting time, and this is somehow cached in XCode?

Personally I'm not interested in those symbols anyway, maybe there's an LLDB setting for this system framework symbol loading to be skipped, or delayed until they are actually needed?

Debugger Configurations

{
    "configurations": [
    {
        "name": "(lldb) Launch",
        "type": "cppdbg",
        "request": "launch",
        "program": "/Users/floh/Library/Developer/Xcode/DerivedData/test-game-bwcgwlktppxrepgyqrpwyczwdpqx/Build/Products/Debug/test-game.app/Contents/MacOS/test-game",
        "args": [],
        "stopAtEntry": true,
        "cwd": "${fileDirname}",
        "environment": [],
        "externalConsole": false,
        "MIMode": "lldb"
    }
    ]
}

Debugger Logs

Debug output log is too long attach, but it's about 1000 lines of lines like this:

Loaded '/System/Library/PrivateFrameworks/LinkServices.framework/Versions/A/LinkServices'. Symbols loaded.

Other Extensions

No response

Additional Information

No response

[floooh]

PS: maybe look into lldb settings like symbols.enable-lldb-index-cache and symbols.load-on-demand, those seem to help a bit when tinkering on the CodeLLDB debug console, still not as fast on followup sessions as Xcode though.

Is there a way to inject an .lldbinit file into the C/C++ Extension debug session?

[github-actions]

Thank you for reporting this issue. We’ll let you know if we need more information to investigate it. Additionally, if you're working with GDB/LLDB, please note that the code is open source at https://github.com/microsoft/MIEngine/wiki/Contributing-Code . Your contributions are always welcome and appreciated.

[transmutrix]

I'm having the same issue.

I'm going to provide a list of things I've tried after reading the LLDB docs and the VS Code launch.json docs, in case that's helpful to anyone else looking at this.

Adding this to ~/.lldbinit didn't do anything:

settings set symbols.load-on-demand true

Adding this to launch.json in setupCommands didn't do anything either:

{
  "text": "settings set symbols.load-on-demand true"
}

Adding a symbolLoadInfo didn't seem to matter either. I tried all manner of wildcards, regex, library names without a path, with a framework extension, without an extension, the fully qualified path to a library, etc. Setting loadAll to false also appeared to make no difference.

"symbolLoadInfo": {
  "loadAll": true,
  "exceptionList": "/System/Library/**"
}

[floooh]

To add another data point:

When building a Zig executable of essentially the same code (e.g. a C library with some Zig code on top), and debugging this with the CodeLLDB extension, there is almost no waiting time. No idea yet why that is, one notable difference (AFAIK) is that Zig has implemented its own linker.

[transmutrix]

Ah, well, you've saved a lot of my time! CodeLLDB boots up in a couple seconds, as it should. 🎉 Thank you.