-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Mac m1 debugger won't start on aspnet core projects, program has exited #46226
Comments
Tagging subscribers to this area: @tommcdon Issue DetailsI am using a Mac m1 on Mac OS 11.1. I can recreate this problem every time. If I create a new webapi, even just dotnet new webapi, I can not launch the app using vsdbg debugger. I am using vscode 1.52.1. The apps just exists. I've seen other issues such as this one #44958, but it's not quite the same as I do not receive any error messages. Here is the tail of the output of the app. Is there some other option I can set in launch to be able to provide more info, to help determine what this issue is, if it's rosetta, or something else? Any ideas appreciated.
|
There is also a new debugger fix for mac to VS Code. See #42311 |
It looks to resemble this post. @sdmaclea I appreciate the links. is that debugger fix something available as a separate download? What I saw in the link was for full vs. I don't mind being patient, just kind of wondering what the general issue is so I know how to look for a fix when it comes out. https://github.com/Azure/azure-functions-core-tools/issues/2303 |
Hello. On this issue, is the consensus that it is some type of regression related to ARM or the M1, and it might get fixed over the next month or two? Any insight is appreciated. I was not able to download a fix for debugger as noted above -- or was just confused on how to get to that link. |
This could easily be one or both issues known Mac arm issues. (I edited my previous posts because one of the cited issues was incorrect.) I don't know how VS Code releases. @DavidKarlas comment in #42311 seemed to know where to look and might provide more info. For Rosetta, Apple is releasing fixes in new Big Sur betas. Several of the fixes went into the 11.2 beta, however the community feedback is that the 11.2 beta made things a bit worse. @zwarich is updating #44897 as Apple releases fixes. See #44897 (comment) |
I was looking at https://github.com/OmniSharp/omnisharp-vscode/releases/tag/v1.23.8 looking also at https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.csharp it appears VSCode released fix for XCode 12 problem... I suggest that you check if you have installed version 1.23.8 |
@DavidKarlas I do have 1.23.8 installed (thank you for the info). @sdmaclea |
I am going to close this issue here, and file against omnisharp, I didn't see a similar issue there already to use. Thank you all for feedback. |
dotnet/vscode-csharp#4315 |
Additional info from Mac console crash log: Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Termination Signal: Segmentation fault: 11 VM Regions Near 0x1111f5748: |
@JasperRev can you please share the whole crash log as a gist? There should be stack traces of all the threads including the one that has crashed. In fact, the bits above show that the thread 0 has crashed, so the stack trace of that thread should be sufficient. |
@janvorli here is the one from vsdbg-ui, I will also add from dotnet crash Process: dotnet [7115] Date/Time: 2020-12-30 07:58:20.030 -0600 Sleep/Wake UUID: CB868706-B30B-4657-A9D7-AA298D3D1AE7 Time Awake Since Boot: 29000 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Termination Signal: Segmentation fault: 11 VM Regions Near 0x1111f5748: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread Thread 1:: com.apple.rosetta.exceptionserver Thread 2: Thread 3: Thread 4: Thread 5: Thread 6: Thread 7: Thread 8: Thread 9: Thread 10: Thread 11: Thread 12: Thread 13: Thread 14: Thread 15: Thread 16: Thread 17: Thread 18: Thread 19: Thread 20: Thread 0 crashed with X86 Thread State (64-bit): Binary Images: Translated Code Information: External Modification Summary: VM Region Summary:
REGION TYPE SIZE COUNT (non-coalesced) |
this is from vsdbg-ui -- sorry above is from dot net. Process: vsdbg-ui [7114] Date/Time: 2020-12-30 07:58:20.101 -0600 Sleep/Wake UUID: CB868706-B30B-4657-A9D7-AA298D3D1AE7 Time Awake Since Boot: 29000 seconds System Integrity Protection: enabled Crashed Thread: 18 Exception Type: EXC_CRASH (SIGABRT) Application Specific Information: Thread 0:: Dispatch queue: com.apple.main-thread Thread 1: Thread 2: Thread 3: Thread 4: Thread 5: Thread 6: Thread 7: Thread 8: Thread 9: Thread 10: Thread 11: Thread 12: Thread 13:: com.apple.rosetta.exceptionserver Thread 14: Thread 15: Thread 16: Thread 17: Thread 18 Crashed: Thread 18 crashed with X86 Thread State (64-bit): Binary Images: Translated Code Information: External Modification Summary: VM Region Summary:
REGION TYPE SIZE COUNT (non-coalesced) |
This is a dup of #42489, it happens on x64 macOS too. I have described the culprit in my comment over there: #42489 (comment) |
@janvorli thanks for the info and your comments. I am not sure where to go with this. What I mean is, this didn't happen on my x64 Mac, but it does now on my m1 MacBook Pro (and 100% of the time in aspnetcore apps). I can debug console apps for what it's worth. Until this is addressed (by someone?), it really makes development on a Mac challenging to debug (without a bunch of console.writelines). |
Actually, this crash happens when the debugger is exiting. So I guess the issue that you are seeing on the M1 is a crash in the application itself. Let me check the log of the application itself. |
@JasperRev looking at the application crash itself, I actually think it is likely an issue that will be fixed in some upcoming macOS beta release. I remember seeing a stack trace like yours locally. I have reported two debugger issues to Apple and they have fixed one of them in 11.1 and another fix is expected to appear in a future beta release. Basically, debugging doesn't work at all without these fixes. The fix in 11.1 allowed plain hello world app to start under the debugger and stop on a breakpoint, but it is not possible to continue execution or single step after that. |
@janvorli thank you! that makes sense! appreciate it. |
I am using a Mac m1 on Mac OS 11.1. I can recreate this problem every time. If I create a new webapi, even just dotnet new webapi, I can not launch the app using vsdbg debugger. I am using vscode 1.52.1.
The apps just exists. I've seen other issues such as this one #44958, but it's not quite the same as I do not receive any error messages.
Here is the tail of the output of the app. Is there some other option I can set in launch to be able to provide more info, to help determine what this issue is, if it's rosetta, or something else? Any ideas appreciated.
Loaded '/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App/3.1.10/Microsoft.Extensions.Configuration.FileExtensions.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. Loaded '/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App/3.1.10/Microsoft.Extensions.Configuration.Json.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. Loaded '/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App/3.1.10/Microsoft.Extensions.Configuration.UserSecrets.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. Loaded '/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App/3.1.10/Microsoft.Extensions.Configuration.Binder.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/3.1.10/System.Private.Uri.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/3.1.10/System.Buffers.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/3.1.10/System.IO.FileSystem.Watcher.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/3.1.10/System.ComponentModel.Primitives.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/3.1.10/System.Collections.Concurrent.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. Loaded '/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App/3.1.10/Microsoft.Extensions.FileSystemGlobbing.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/3.1.10/System.Threading.Timer.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/3.1.10/System.Threading.Thread.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. The program '[2705] webapi.dll' has exited with code 0 (0x0).
The text was updated successfully, but these errors were encountered: