libsosplugin.dylib: CoreCLR host crash on macOS Sonoma 14.4 on arm64 #4551
Comments
|
/cc @hoyosjs |
|
This looks like a runtime issue not SOS's. CorUnix::CPalThread::EnableMachExceptions()'s call to thread_swap_exception_ports in the runtime's PAL. I'm not sure what SOS can do about it. |
|
yea, it's a runtime issue. Just wanted to bring it up here in case anyone else runs into it |
|
I brought it up because there is nothing we can do in the diagnostics repo to fix it that maybe it should be a runtime repo issue. |
|
I can reproduce as well. If I Maybe move this issue to the runtime repo if that's where it should be? |
|
@rolfbjarne I was going to open a new issue for dotnet/runtime with just a barebones LLDB plugin that hosts CoreCLR so that it's easier to reproduce. it's still on my todo list - I just need to clean up my repro. |
|
Not sure if it's related, but the JVM folks discovered that https://bugs.java.com/bugdatabase/view_bug?bug_id=8327860 (see in particular the repro from 12-03-2024, reproduced below: #include <stdio.h>
#include <sys/mman.h>
#include <pthread.h>
int main() {
pthread_jit_write_protect_np(0);
char* mem = (char*)mmap(0, 16 * 1024, 0, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0);
fprintf(stderr, "addr = %p\n", mem);
char value = *mem;
fprintf(stderr, "value = %c\n", value);
return 0;
}macOS 14.3: SIGBUS |
|
I opened dotnet/runtime#99977 to track potential runtime work. I think it's worthwhile to keep this diagnostics issue open since this is probably where folks will look for SOS issues. |
|
A workaround is to use a non-Apple |
|
Have you successfully loaded a x64 libsosplugin.dylib under the brew installed lldb? We tried recently and /cc: @mikelle-rogers |
Description
After installing
dotnet-sosand adding then installing the plugin usingdotnet-sos install, I get a crash as soon as the plugintries to initialize the coreclr host.
Note this is different from #4259 where the coreclr host fails to initialize but at least it doesn't kill the lldb session.
The new behavior is that lldb completely dies. Looking in
Console.app, I see the following stack trace:Note
CorUnix::CPalThread::EnableMachExceptions()crashing in a call tothread_swap_exception_portsdue to anEXC_GUARDGUARD_TYPE_MACH_PORTmach exception. Looking around it seems like (see this StackOverflow answer) this is because the exception port for the LLDB process is guarded now. Possibly this is new in macOS 14.4.The text was updated successfully, but these errors were encountered: