runtime: Debugging not working with XCode 12 selected
Description
In VSMac, we are using vsdbg(same as Omnisharp) to debug .NET Core applications… We have unit tests, but ever since bumping XCode from 11 to 12, debugging started failing… So here are repro steps:
sudo xcode-select -s /Applications/Xcode_12.appmkdir xcodeTestProjcd xcodeTestProjdotnet new consoledotnet publish --runtime osx-x64code .- create
launch.jsonvia VSCode, and change:
"program": "${workspaceFolder}/bin/Debug/net5.0/xcodeTestProj.dll",- to
"program": "${workspaceFolder}/bin/Debug/net5.0/osx-x64/publish/xcodeTestProj.dll",
- Start debugging
- Observe Debug Console print
Unable to attach to CoreCLR. Unknown Error: 0x80131c3c
Now try all steps, but change step 1 to sudo xcode-select -s /Applications/Xcode_11.app(notice change of Xcode version), it will work fine.
I tried to change to not use published version… But when tests are executing they fail either wrong variables values are reported or “Unable to evaluate expression because the code is optimized o…”.(Only when using XCode 12, fine with XCode 11). I believe underlining problem is same, hence I suggest trying debugging published app since its easier repro…
Im not sure how is selecting XCode 12 vs 11 effecting debugging of CoreCLR, but it does, I suspect its something related to lldb or some libraries used…
Configuration
- Which version of .NET is the code running on? 3.1, but also tried with 5.0
- What OS and version, and what distro if applicable? macOs
- What is the architecture (x64, x86, ARM, ARM64)? x64
- Do you know whether it is specific to that configuration? Yes(macOs)
- If you’re using Blazor, which web browser(s) do you see this issue in? N/A
Regression?
No.
Other information
We have to disable .NET Core unit tests for until this is resolved, but I also believe this will effect users when doing some complex debugging.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 6
- Comments: 38 (15 by maintainers)
Re workaround:
It seems that downloading and installing the “Command Line Developer Tools for Xcode 11.5” (
*.dmg, contains an installer package (*.pkg), about 260MB) from https://developer.apple.com/download/more/ is sufficient (no need for Xcode 11 as a whole).Once installed, switch to this version of the tools with
sudo xcode-select -s /Library/Developer/CommandLineToolsI can confirm this workaround.
Xcode_11cd /sudo xcode-select -s /Applications/Xcode_11.appNow everything works for me.
The fix had been merged in time to make it into our next official build. After that it needs to be picked up by the different debuggers in the ecosystem. VS for mac and VSCode use the same debugger engine and the owners expressed interest in including the fix as soon as possible.
Thanks!
The direct link to the Xcode 11.7 file didn’t work for me.
In case anyone else is having trouble, go to Apple’s More Downloads for Apple Developers page and search
Xcode 11.7👍Yes, soon after 5.0.1 ships the VS debugger team expects to put out a new release of vsdbg-ui which can be included into the VS Code C# extension and VS For Mac.
Ran a test of this fix and it looks good to me with Xcode 12.2.
I am assuming there will be a more official debugger zip at some point with this updated libdbgshim.dylib that can be bundled with OmniSharp and VS Mac?
VS4M version 8.8.4.30 which contains a fix for this issue is available by now: https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2019-mac-relnotes#884
Issue can probably get closed.
@kuromukira There should be a new VS Mac 8.8.4 release with the updated debugger at some point - I do not have a specific date as yet.
For a workaround you can probably copy the libdbgshim.dylib from /usr/local/share/dotnet/shared/Microsoft.NETCore.App/5.0.1/libdbgshim.dylib into VS Mac’s app bundle
/Applications/Visual\ Studio.app/Contents/Resources/lib/monodevelop/AddIns/DotNetCore.Debugger/Adapter/libdbgshim.dylib- making a backup copy of this file in the Adapter directory so you can rollback if it breaks something.@mrward Thank you for the hint. This did the work for me 🙂
@sdmaclea Because this is a dbgshim fix - it doesn’t need to be. Any debugger that wants this fix can use the .NET 5 dbgshim.
@kuromukira you can use the workarounds posted above to debug normally. Using an older copy of Xcode. Its pretty easy to switch back and forth if you also do other things with Xcode 12.
This is most likely fixed by https://github.com/dotnet/runtime/pull/42900
Hi @tommcdon @hoyosjs,
Im wonder how could priority on this be increased so someone takes a look at this since more and more developers will start switching to XCode 12 since it was released last week, and milestone .NET 6 feels too far away… At first I though this would only be problem for unit tests but looks like its effecting also developers…
Regards, David