Debugger doesn't attach on macOS 26

[richlander]

Trying to test simple apps on macOS 26, with VS Code Insiders and C#DK (all latest).

------------------------------------------------------------------------------
You may only use the Microsoft Visual Studio .NET/C/C++ Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software to help you
develop and test your applications.
------------------------------------------------------------------------------
Hello, World!
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
The program '[12023] test' has exited with code 0 (0x0).

I am seeing this error. It happens with both .NET 9 and .NET 10 latest. It was not happening on Sequoia.

[richlander]

@dotnet/dotnet-diag

[Phuoc-dekkpro]

did you resolved this issue? @richlander

[richlander]

No. It remains open. The people we need are the same ones at dotnet/diagnostics#5323. I am talking to them.

I doubt it matters, but are you on x64 or Arm64 @Phuoc-dekkpro? I assume everything was working before your upgrade. Yes?

[Phuoc-dekkpro]

Yes @richlander, It's working fine before upgrade.
I am using Arm64.

[Phuoc-dekkpro]

Hi @richlander , Please share me the solution if you can resolved this issue., it really difficult when. develop

[Phuoc-dekkpro]

{
    "version": "0.2.0",
    "configurations": [
        {
            // Use IntelliSense to find out which attributes exist for C# debugging
            // Use hover for the description of the existing attributes
            // For further information visit https://github.com/dotnet/vscode-csharp/blob/main/debugger-launchjson.md.
            "name": "ppp.NET Core Launch (web)",
            "type": "coreclr",
            "request": "launch",
            "preLaunchTask": "build",
            // If you have changed target frameworks, make sure to update the program path.
            "program": "${workspaceFolder}/src/xxx/bin/Debug/net8.0/xxxxx.dll",
            "args": [],
            "cwd": "${workspaceFolder}/src/xxxx",
            "stopAtEntry": false,
            // Enable launching a web browser when ASP.NET Core starts. For more information: https://aka.ms/VSCode-CS-LaunchJson-WebBrowser
            "serverReadyAction": {
                "action": "openExternally",
                "pattern": "\\bNow listening on:\\s+(https?://\\S+)"
            },
            "env": {
                "ASPNETCORE_ENVIRONMENT": "Development"
            },
            "sourceFileMap": {
                "/Views": "${workspaceFolder}/Views"
            }
        },
        {
            "name": ".NET Core Attach",
            "type": "coreclr",
            "request": "attach"
        }
    ]
}

[Phuoc-dekkpro]

I fixed it by this launch.json @richlander

[eterekhin]

Can confirm, running under debugger doesn't work. Even though attach is working

Debugger sequentially calls CreateProcessForLaunch(bSuspendProcess=1), RegisterForRuntimeStartup, ResumeProcess.
After RegisterForRuntimeStartup call m_startupSem is successfully created here
After ResumeProcess runtime can't open semStartup semaphore in PAL_NotifyRuntimeStarted, for some reason it is considered to not exist (please see logs attached below)

In logs(stripped) it looks so:

PAL_RuntimeStartupHelper.Register creating startup '/clrst00004d9300000000684a8863' continue '/clrco00004d9300000000684a8863'
PAL's StartupHelperThread starting
IsCoreClrProcessReady: stat(/var/folders/6s/88nfy3mj1mj3sdkp_nhlffdr0000gp/T/clr-debug-pipe-19859-1749715043-in) FAILED: errno is 2 (No such file or directory)
sem_wait(startup)
// here runtime part starts
PAL_NotifyRuntimeStarted opening continue '/clrco00004d9300000000684a8863' startup '/clrst00004d9300000000684a8863'
sem_open(/clrst00004d9300000000684a8863) failed: 2 (No such file or directory)

Hope it helps!

[hoyosjs]

I think this might be related to:

@description: Calls to sem_open or sem_unlink from a process signed with a Team ID entitlement no longer observe any semaphores created by processes signed with different Team IDs. Named semaphores are now scoped to a single development team. (123476459)

[eterekhin]

@hoyosjs, Thank you for pointing that out! I got debugger working after codesign --force -s - /path/to/debugger, same way as dotnet sdk does for executables

I am curious if we may want to work it around in diagnostics?
As an example, we could create another child process from dbgshim that would manage the semaphores and signals to dbgshim via pipes.
(I tried creating a semaphore between fork and execv from CreateProcessForLaunch, but that didn't work, runtime was not able to find the semaphore)
That's an alternative to having debuggers unsigned