-
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
Crash while debugging on MacOS #42489
Comments
Tagging subscribers to this area: @tommcdon |
@ar0311 is there any chance you can share your app or a smaller repro? And could you please describe what type of operations were you doing under the debugger? That stack just shows me that a COM object pointer's destructor resulted an access violation (probably dangling pointer). It's likely one of the |
That stack should be ignored - that shows vsdbg crashing on shutdown after whatever problem occurred. |
@hoyosjs I can post one of the full stack traces if you like, I was just trying to save space. I will work on getting a repro up over the weekend. |
Process: vsdbg-ui [42595] Date/Time: 2020-09-19 12:18:43.456 +1000 Sleep/Wake UUID: B9F9158C-93D1-4A40-91B6-8063F062C285 Time Awake Since Boot: 160000 seconds System Integrity Protection: enabled Crashed Thread: 15 Exception Type: EXC_BAD_ACCESS (SIGSEGV) External Modification Warnings: 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: Thread 14: Thread 15 Crashed: Thread 15 crashed with X86 Thread State (64-bit): Logical CPU: 2 Binary Images: External Modification Summary: VM Region Summary:
REGION TYPE SIZE COUNT (non-coalesced) |
Process: vsdbg-ui [75543] Date/Time: 2020-10-11 13:42:00.645 +1100 Sleep/Wake UUID: B3E41C77-E645-4A7D-9F62-4A4CBFE6F71D Time Awake Since Boot: 400000 seconds System Integrity Protection: enabled Crashed Thread: 18 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Termination Signal: Segmentation fault: 11 External Modification Warnings: 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: Thread 14: Thread 15: Thread 16: Thread 17: Thread 18 Crashed: Thread 18 crashed with X86 Thread State (64-bit): Logical CPU: 0 Binary Images: External Modification Summary: VM Region Summary:
REGION TYPE SIZE COUNT (non-coalesced) |
@gregg-miskelly even though it is triggered by the runtime exiting, this is a crash in libvsdbg.dylib at process exit in ATL::CComPtr::~CComPtr. This means that there is a static variable of CComPtr type somewhere in the library and the destructor is most likely touching some object that doesn't exist anymore. Using static variables of types with destructors is error prone as the order of their shutdown is not deterministic and happens after some parts of the runtime are not in working state anymore. We've had many issues with things like this in the coreclr until we've eliminated usage of statics with destructors. This specific shutdown is actually a shutdown in response to SIGTERM, which means that another process or user has sent this signal to the current process to ask it exit cleanly. Copying the crash call stack from the crash log above for better visibility:
|
@gregg-miskelly The problem is that the host ASP.NET host (Server project in Blazor Wasm Hosted scenario) was crashing silently on startup during debugging. Was OK when just run from command line outside the debugger. Interestingly, it does not seem to be happening after moving to 5.0 RC2 SDK and packages. Perhaps a very recent change to vsdbg? |
Tagging subscribers to this area: @thaystg |
Seems to be a blazor/wasm issue, moving to mono-diagnostics |
@ar0311 Version 1.23.3 of the C# extension came out yesterday. So if you have that, maybe that is what fixed your problem? Though if you are in a Blazor Wasm scenario, I am not sure why vsdbg-ui is even involved. Anyway, if you can no longer reproduce the problem, should this issue be closed? |
@gregg-miskelly In blazor hosted scenario there is an ASP.NET core Kestrel server process serving the static wasm site and any API you may have. This is the process crashing silently under the debugger. The WASM app continues in the browser. |
Process: vsdbg-ui [33816] Date/Time: 2020-10-16 11:20:24.636 +1100 Sleep/Wake UUID: BC63D559-5AC3-4661-8391-506A773072E3 Time Awake Since Boot: 110000 seconds System Integrity Protection: enabled Crashed Thread: 17 Exception Type: EXC_CRASH (SIGABRT) External Modification Warnings: 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: Thread 14: Thread 15: Thread 16: Thread 17 Crashed: Thread 17 crashed with X86 Thread State (64-bit): Logical CPU: 0 Binary Images: External Modification Summary: VM Region Summary:
REGION TYPE SIZE COUNT (non-coalesced) |
Just repro'd with dotnet new blazorwasm --auth Individual -ho -o blazorwasmhosted. "hosted": true, Crashed after attempting login (after registering new user) (.NET 5.0 SDK RC2) |
Another crash, not sure if related, this time theres an exception in the debug console:
|
This last one is an application crash because there's too many file descriptors in use. I think I am a little confused on the scenario here. What process are you debugging, the client (WASM) or the server? And if it's the server, will the new command you posted generate both a client and a server? |
Yes debugging both, and yes the command generated a client and server project. The Server ASP.NET Kestrel server crashes, the WASM running in browser continues (obviously useless as the backend has failed). Process remains after stopping debugging and must be killed manually: 34929 ?? 0:23.69 /usr/local/share/dotnet/dotnet /Users/me/Repos/blazorauthtest/Server/bin/Debug/net5.0/blazorauthtest.Server.dll |
Clean reboot seems to have solved it for now. Closing. |
Spoke too soon - in system.log Oct 16 12:49:41 MacBook-Pro vsdbg-ui[1398]: vsdbg-ui(1398,0x700000c53000) malloc: *** error for object 0x7fdaae43fab0: pointer being freed was not allocated |
I tried for a bit but the client and server don't properly communicate. I'll check next week. |
The issue in the newly reported logs remains the same as I've described in my comment above: #42489 (comment) |
Can we close this issue, I think it's not happening anymore, right? |
We can close and if someone reports it again we'll need a new issue - things have moved a lot since then and we haven't read back.. |
Description
While running under debugger (vsdbg-ui) on MacOS and VS Code, app always crashes silently (no exception or other console output in debugger console). App seems to run fine when run using dotnet run without debugging, and the problem also doesn't seem to exist when I run it on Windows (debug or console).
Configuration
.NET 5.0 RC1 and latest RC2 SDK
MacOS 10.13.6 (High Sierra)
x64
Regression?
Problem seems to have started when moving from 3.1 to 5.0 builds.
Other information
As there is no output generated when crashing, here are the logs from Mac Console (crash report) app:
Process: vsdbg-ui [43935]
Path: /Users/USER/*/vsdbg-ui
Identifier: vsdbg-ui
Version: 0
Code Type: X86-64 (Native)
Parent Process: Code Helper (Renderer) [30580]
Responsible: Electron [4546]
User ID: 501
Date/Time: 2020-09-19 14:49:52.146 +1000
OS Version: Mac OS X 10.13.6 (17G14019)
Report Version: 12
Anonymous UUID: 793A42C9-0177-8AFE-BB62-3F16080B727D
Sleep/Wake UUID: EAB4009A-FD23-4A47-B0B8-8CBB6EAF310A
Time Awake Since Boot: 160000 seconds
Time Since Wake: 1700 seconds
System Integrity Protection: enabled
Crashed Thread: 15
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT
External Modification Warnings:
Process used task_for_pid().
----truncated threads 0 - 14 ----
Thread 15 Crashed:
0 libvsdbg.dylib 0x000000010d22917f ATL::CComPtr::~CComPtr() + 15
1 libsystem_c.dylib 0x00007fff50050eed __cxa_finalize_ranges + 351
2 libsystem_c.dylib 0x00007fff500511fe exit + 55
3 libcoreclr.dylib 0x000000010c39b02d PROCEndProcess(void*, unsigned int, int) + 221
4 libcoreclr.dylib 0x000000010c39af38 ExitProcess + 152
5 libcoreclr.dylib 0x000000010c598629 EEPolicy::ExitProcessViaShim(unsigned int) + 9
6 libcoreclr.dylib 0x000000010c5985e7 SafeExitProcess(unsigned int, int, ShutdownCompleteAction) + 487
7 libcoreclr.dylib 0x000000010c395507 CorUnix::TerminationRequestHandlingRoutine(void*) + 23
8 libcoreclr.dylib 0x000000010c39eae4 CorUnix::CPalThread::ThreadEntry(void*) + 436
9 libsystem_pthread.dylib 0x00007fff502bc661 _pthread_body + 340
10 libsystem_pthread.dylib 0x00007fff502bc50d _pthread_start + 377
11 libsystem_pthread.dylib 0x00007fff502bbbf9 thread_start + 13
The text was updated successfully, but these errors were encountered: