Omnisharp-vscode: All debugging broken on MacOS Sierra (10.12.4?)

[sunmorgus]

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-rc3-004530)

Product Information:
 Version:            1.0.0-rc3-004530
 Commit SHA-1 hash:  0de3338607

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /usr/local/share/dotnet/sdk/1.0.0-rc3-004530

VS Code version: Version 1.9.1 (1.9.1)
C# Extension version: 1.7.0

Steps to reproduce

1. Open dotnet core c# project
2. Launch the debugger
3. Wait for project to build

Expected behavior

The debugger launches and allows me to debug the code

Actual behavior

An error is returned in the output window:

--------------------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (clrdbg) with Visual Studio
Code, Visual Studio or Visual Studio for Mac software to help you develop and
test your applications.
--------------------------------------------------------------------------------
ERROR: Unable to start debugging. Unexpected CLRDBG output from command "-exec-run".
The program '/Users/nicklasdemayo/aaa/projects-git/Service-BAHAdmin/BAH.Admin/bin/Debug/netcoreapp1.1/BAH.Admin.dll' has exited with code 42 (0x0000002a).

I ran the following (suggested from here):

/Users/nicklasdemayo/.vscode/extensions/ms-vscode.csharp-1.7.0/.debugger/clrdbg --interpreter=mi
-gdb-exit

And got no other unexpected output.

[gregg-miskelly]

@sunmorgus could you enable engineLogging (hopefully the quick way will work) and add the relevant sections around '-exec-run' to this bug?

[sunmorgus]

The quick way appeared to work. I copied everything from the 1011-exec-run line down, let me know if you need more.

1: (686) <-1011-exec-run 1: (11041) ->=telemetry,event-name="VS/Diagnostics/Debugger/clrdbg/LaunchFailed",properties={VS.Diagnostics.Debugger.clrdbg.ErrorCode="0x80070057",VS.Diagnostics.Debugger.clrdbg.Version="15.0.26013.0 built by: PREVIEW.DBG2",VS.Diagnostics.Debugger.clrdbg.OSFamily="Darwin",VS.Diagnostics.Debugger.clrdbg.KernelRelease="16.5.0"} 1: (11042) ->1011^error,msg="" 1: (11042) ->(gdb) E output: {"category":"telemetry","output":"VS/Diagnostics/Debugger/clrdbg/LaunchFailed","data":{"VS.Diagnostics.Debugger.clrdbg.ErrorCode":-2147024809,"VS.Diagnostics.Debugger.clrdbg.Version":"15.0.26013.0 built by: PREVIEW.DBG2","VS.Diagnostics.Debugger.clrdbg.OSFamily":"Darwin","VS.Diagnostics.Debugger.clrdbg.KernelRelease":"16.5.0"},"type":"output"} 1: (11044) 1011: elapsed time 10358 E output: {"category":"stderr","output":"ERROR: Unable to start debugging. Unexpected CLRDBG output from command \"-exec-run\".\n","data":null,"type":"output"} ERROR: Unable to start debugging. Unexpected CLRDBG output from command "-exec-run". 1: (11055) <--gdb-exit 1: (11056) ->^exit 1: (11061) <-logout E output: {"category":"console","output":"The program '/Users/nicklasdemayo/aaa/projects-git/Service-BAHAdmin/BAH.Admin/bin/Debug/netcoreapp1.1/BAH.Admin.dll' has exited with code 42 (0x0000002a).\r\n\n","data":null,"type":"output"} The program '/Users/nicklasdemayo/aaa/projects-git/Service-BAHAdmin/BAH.Admin/bin/Debug/netcoreapp1.1/BAH.Admin.dll' has exited with code 42 (0x0000002a). E exited: {"exitCode":42,"type":"exited"} E terminated: {"type":"terminated"} E output: {"category":"telemetry","output":"VS/Diagnostics/Debugger/DebugCompleted","data":{"VS.Diagnostics.Debugger.ImplementationName":"Microsoft.MIDebugEngine","VS.Diagnostics.Debugger.EngineVersion":"14.0.31028.1","VS.Diagnostics.Debugger.HostVersion":"1.0.30207.1","VS.Diagnostics.Debugger.AdapterId":"coreclr","VS.Diagnostics.Debugger.DebugCompleted.BreakCounter":0},"type":"output"} C disconnect: {"restart":false} R: {"success":true,"message":null,"request_seq":6,"command":"disconnect","body":null,"running":false,"refs":null,"seq":0,"type":"response"}

[gregg-miskelly]

@sunmorgus got it. So it looks like '-exec-run' is failing with E_INVALIDARG (0x80070057), which we don't provide a description for, and that results in this bad error message. Unfortunately that doesn't tell us much about the root cause for where the E_INVALIDARG might be coming from. If you scroll up a little bit where you should see the program path, working directory, and arguments passed, does anything by chance look 'weird'?

[sunmorgus]

@gregg-miskelly I do see this error a little further up:

1: (501) ->(gdb)
1: (501) <-1006-break-insert main
1: (501) ->1006^error,msg="-break-insert currently only supports file/line breakpoints"
1: (501) ->(gdb)
1: (501) 1006: elapsed time 0

However, I took a look at the program path, working directory, and arguments, but nothing sticks out to me as being off...

[gregg-miskelly]

@sunmorgus that error is actually normal / ignorable. Hmm... I am not quite sure how to troubleshoot this.

Do you get this problem for all projects?

[sunmorgus]

@gregg-miskelly I went and created a new project, and the same issue occurred.

Also, I feel I should mention (and probably should have earlier, sorry)... this issue started occurring after 2 events this morning:

1. Installing Visual Studio for Mac (and the supporting Mono framework stuff). I tried removing all of that (as well as removing and reinstalling OmniSharp in vscode), but that didn't help.
2. I also updated this morning to macOS 10.12.4 Public Beta Version 2, but that would be a difficult one to roll back.

It's hard to say whether or not either of those caused the issue I suppose, but they are about the only things I can think of that changed recently.

[gregg-miskelly]

@sunmorgus Thanks. I will see if I can reproduce this on that OS.

[stevepentland]

Hoping a solution may be found soon, I am also experiencing this issue when trying to debug.

Both on a simple "Hello, World" project, and more advanced code.

Exact same OS version as @sunmorgus with same environment also.

[Griesmar]

Same situation here, also with macOS 10.12.4 Beta 2.

[sunmorgus]

Other things I've tried/noticed:

1. It _almost_ feels like it's having an issue reading the stdin. I had a simple python script I was trying to run recently that was supposed to take input from the stdin, but it wasn't able to for some reason. I didn't dig into it much, but maybe they are related?
2. I verified that it wasn't an issue with my dotnet core install by reinstalling it, making sure to complete the openssl req as well.
3. I'm keeping an eye out for a new update to the public beta, and I'm going to submit feedback to Apple as well.

[LukeStephen]

I am getting this same error all of a sudden, worked fine yesterday, but last night my MacOS did update to 10.12.4 Public Beta 2.

Builds fine, but can't debug any longer, any ideas?

ERROR: Unable to start debugging. Unexpected CLRDBG output from command "-exec-run".
WebApp-OpenIDConnect-DotNet.dll' has exited with code 42 (0x0000002a).

[dbogatov]

Same for me.
Updated to macOS 10.12.4 beta 2.

[mshulman]

Also able to repro: On 10.12.4 Beta (16E154a)

Terminal window in vscode:
bash-3.2$ /Users/mshulman/.vscode/extensions/ms-vscode.csharp-1.7.0/.debugger/clrdbg --interpreter=mi =message,text="--------------------------------------------------------------------------------\nYou may only use the Mic rosoft .NET Core Debugger (clrdbg) with Visual Studio\nCode, Visual Studio or Visual Studio for Mac software to help you develop and\ntest your applications.\n--------------------------------------------------------------------------------\n" ,send-to="output-window" (gdb) -gdb-exit ^exit

My generated launch.json is

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": ".NET Core Launch (console)",
            "type": "coreclr",
            "request": "launch",
            "preLaunchTask": "build",
            "program": "${workspaceRoot}/bin/Debug/netcoreapp1.1/hello.dll",
            "args": [],
            "cwd": "${workspaceRoot}",
            "externalConsole": false,
            "stopAtEntry": false,
            "internalConsoleOptions": "openOnSessionStart"
        },
        {
            "name": ".NET Core Attach",
            "type": "coreclr",
            "request": "attach",
            "processId": "${command.pickProcess}"
        }
    ]
}

[mshulman]

I thought I'd be able to work around this by launching my app, then attaching the debugger. Unfortunately, I get the same message.

[LukeStephen]

I ended up downloading the latest stable MacOS version from apple's developer site and it installed back to the pre-beta version without effecting anything that was installed on my MacBook. With that this error was gone, no beta for me till this is resolved...

[stevepentland]

Error still occurs, 10.12.4 beta 3 release of macOS.

[sunmorgus]

It happens in visual studio for Mac is well.

--
Nick DeMayo

On February 21, 2017 at 8:31:21 AM, Steve Pentland ([email protected])
wrote:

Error still occurs, 10.12.4 beta 3 release of macOS.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OmniSharp/omnisharp-vscode/issues/1220#issuecomment-281344718,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACLmcNjUUI_UOFjD-mBxueI1WDqwUOABks5reucpgaJpZM4L9eD1
.

[lt72]

@noahfalk FYI

[gregg-miskelly]

This issue is caused by an issue with a CoreCLR component. I opened https://github.com/dotnet/coreclr/issues/9730 to track the problem.

[robvdveer]

I have the same error since upgrading to macOS 10.12.4 beta 2 and 3. Not only Visual Studio for Mac but also VSCode stopped working for me. I'll try reverting to stable 10.12.3 to see if that 'solves' the issue of not being able to debug.

[sunmorgus]

It seems that 1.8.0-beta2 made progress towards a resolution here... I'm now able to at least start the project inside of vscode, but I get a new error message Unable to attach to CoreCLR:

-------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------
Unable to attach to CoreCLR.
Hosting environment: Development
Content root path: [redacted]
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.

I can see that the extension is now using vsdbg rather than clrdbg and that is has options for vscode specifically. I tried running the below to see if I'd get any expected output (grasping at straws here... not entirely certain what I'm even doing is correct):

./vsdbg --interpreter=vscode --engineLogging=vsdbg.log --attach --name dotnet

But got no errors or anything in the log file. I then tried to run with logging enabled in my launch.json, and got the following:

-------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------
<- (R) {"seq":4,"type":"response","request_seq":2,"success":true,"command":"launch"}
<- (E) {"seq":5,"type":"event","event":"initialized","body":{}}
-> (C) {"command":"setExceptionBreakpoints","arguments":{"filters":["user-unhandled"]},"type":"request","seq":4}
<- (R) {"seq":6,"type":"response","request_seq":4,"success":true,"command":"setExceptionBreakpoints"}
-> (C) {"command":"configurationDone","type":"request","seq":5}
-> (C) {"command":"threads","type":"request","seq":6}
<- (E) {"seq":7,"type":"event","event":"output","body":{"category":"telemetry","output":"VS/Diagnostics/Debugger/vsdbg/ProcessCreate","data":{}}}
<- (E) {"seq":8,"type":"event","event":"output","body":{"category":"telemetry","output":"VS/Diagnostics/Debugger/Launch","data":{"VS.Diagnostics.Debugger.AdapterId":"coreclr","VS.Diagnostics.Debugger.EngineVersion":"15.1.10304.1 commit:0a2ee19c307840c225785923f285f78e87db4c43","VS.Diagnostics.Debugger.ImplementationName":"vsdbg","VS.Diagnostics.Debugger.Launch.Duration":70}}}
<- (R) {"seq":9,"type":"response","request_seq":5,"success":true,"command":"configurationDone"}
<- (R) {"seq":10,"type":"response","request_seq":6,"success":true,"command":"threads","message":"","body":{"threads":[]}}
<- (E) {"seq":11,"type":"event","event":"output","body":{"category":"stderr","output":"Unable to attach to CoreCLR. "}}
Unable to attach to CoreCLR. 

[gregg-miskelly]

@sunmorgus I debugged the issue and we are fairly certain we know what is going wrong. The underlying issue is a problem with CoreCLR (see above CoreCLR bug). We are leaving this issue open as we will need to update the debugger to a new CoreCLR once there is a fix from the CLR team.

[robvdveer]

I rolled back the osX beta update and that fixed my issue and i was able to run the debugger.

[sunmorgus]

@robvdveer How do I roll it back? Do I have to do a clean install to do that?

[LukeStephen]

I rolled back too, to fix this... go to apple developer portal, download the latest non beta version of Mac OS and install it. It didn't wipe anything for me, I was able to debug in VSCode as soon as it booted back up. MAKE SURE you disable updating back to beta in Mac Settings, otherwise you are back where you started, happened to me once...

[sunmorgus]

Sigh... I'm on the public beta and don't have access to the developer portal :(

[robvdveer]

Can't you find the nonbeta download in your app store history.

[sunmorgus]

I don't see it in the purchase history... I got the laptop on January 20th (ish), with Sierra already loaded.

[robvdveer]

If your lapto is not even a month old just do a recovery reset after you make a backup.

[mikem8361]

@gregg-miskelly: Is this the same problem as issue https://github.com/dotnet/coreclr/issues/9730 (launch fails on Sierra because the vmmap output changed)?

[gregg-miskelly]

@mikem8361: Yes. The two bugs are linked above.

[poorboss3]

Similar issue on WIN 10 X64

[xuzhuoyi]

Error still occurs, 10.12.4 beta 4(16E183b) release of macOS.

[gregg-miskelly]

@poorboss3 your issue is NOT similar if it is happening on Windows. If you would like help, please open a new bug.

[LukeStephen]

Mac OS Sierra 10.12.4 (non-Beta) was released to the public today and this breaks .NET core from working on anyone's Mac running the latest version of Mac OS...

[gregg-miskelly]

@LukeStephen :( I hope to have a beta release out later this week with the fix. I will see if I can put a work around together today using unofficial bits.

[LukeStephen]

Thanks! Even having it work inside visual studio code insiders would be good enough for now...

[gkhanna79]

CC @mikem8361 @lt72

[gregg-miskelly]

Here is a work around that worked for me:

1. Download https://dotnet.myget.org/F/dotnet-core/api/v2/package/runtime.osx.10.10-x64.Microsoft.NETCore.Runtime.CoreCLR/1.1.2-servicing-25123-01
2. Open the resulting file as a zip, and copy out runtimes/osx.10.10-x64/native/libdbgshim.dylib
3. Open a terminal
4. cd ~/.vscode/extensions/ms-vscode.csharp-1.8.0/.debugger
5. cp <path-to-extracted-libdbgshim> .

As I said above, but just to repeat here, I expect to have a real fix out soon. But hopefully this will unblock folks in the mean time.

[LukeStephen]

I can confirm this workaround worked for me. Although my extensions directory was ms-vscode.csharp-1.7.0

Thanks!!

[zbseattle]

FYI, I ran into this issue today too, but with Mac OS Sierra 10.12.2, using VS Code, both via "Attach" with one project, and "Launch (web)" with another project.

The project associated with the Attach attempt was a new one I just started exploring today (the MS-birthed, very cool Humanitarian Toolbox AllReady project), and the project associated with the Launch attempt was an existing one that was debuggable just fine as recently as last week.

And I suspect this might be related to a new C# 1.8.0, which VS Code reported needing updating today - so I did. Since I did this in the context of the new project, I initially assumed the problem might be something related to it.

But I can confirm that the problem is fixed now for both projects after following Gregg's instructions above.

Yippee! Thanx much.

[TypicalFooBar]

I ran into this issue on Mac OS Sierra 10.12.3, but the workaround provided by @gregg-miskelly worked! Thank you! I'm not sure what I did to run into this, because it was working yesterday for me.

[alejandrofloresm]

I ran into the same problem today it may be linked to any of the following events:

• Xcode update
• iWork update
• macOS update

I'll go for the macOS update, anyway @gregg-miskelly 's solution worked perfectly.

[gregg-miskelly]

I have posted a new release of the C# extension that includes the fix.

To try it -- use the use the Installing Beta Releases instructions to install v1.9.0-beta2.

[jorgecotillo]

Thanks, is working now, I was having the same issue today.

[southplatte]

macOS 10.12.4 and the beta release has enabled debugging to work as expected for myself as well. Thank you.

[robvdveer]

I am happy to see this working for VSCode now. However, will this patch work for Visual Studio for Mac Preview as well?

[jorgecotillo]

I believe the workaround mentioned above will help you solve the same issue. You can reference here: https://github.com/dotnet/coreclr/issues/10279 -> Haven't tried this approach yet.

[robvdveer]

@jorgecotillo yes thanks that workaround fixed it for me! Back to work!

[DustinCampbell]

@gregg-miskelly: Should this resolved fixed now?

[sunmorgus]

@gregg-miskelly Version 1.8.1 fixed the issue for me as well.

[gregg-miskelly]

@DustinCampbell I was going to resolve this as soon as we pushed to the gallery (since hithub makes it harder to find closed issues and this one is popular).

[gregg-miskelly]

Version 1.8.1 has now been released to the extension gallery, and contains a fix for this issue. Thanks!