Mike McLaughlin
Mike McLaughlin
It looks like it is blocked in the waitpid at line 2459. We are waiting for createdump to finish generating the core dump and exit. Is there a createdump process...
Sorry, I was looking at the PR diff for the line numbers not the current process.cpp source. You are right that line 2460 in the current source is the close(parent_pipe)....
If the stack trace is from a core dump generated by createdump, the crashing thread will be waiting at that point on the waitpid. Isn't the failure from whatever called...
How can I see more recent failures (with a runtime with my new logging) with this test?
Someone from VS Code should look at this (not sure who). I'm not sure what "Canonical DotNet packages" means either. It looks you are using the Microsoft published SDK package...
If they are not the MS official built binaries then the symbol and debugger files necessary to debug have not been published to the MS symbol servers. We don't support...
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.
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.
Have you successfully loaded a x64 libsosplugin.dylib under the brew installed lldb? We tried recently and `plugin load libsosplugin.dylib` failed with `error: this file does not represent a loadable dylib`....