Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
floooh opened this issue Jan 25, 2025 · 2 comments
Labels
bug debugger help wanted Can be fixed in the public (open source) repo.

Comments

@floooh
Copy link

floooh commented Jan 25, 2025

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
Copy link
Author

floooh commented Jan 25, 2025

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?

Copy link

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.

@github-actions github-actions bot added the help wanted Can be fixed in the public (open source) repo. label Jan 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug debugger help wanted Can be fixed in the public (open source) repo.
Projects
None yet
Development

No branches or pull requests

2 participants