dotnet dump analyze's gcroot -all <address> crashes on arm64
#3726
Comments
|
Similar crash with |
|
Do you know if it crashes when you run the same commands from lldb with the sos plugin? |
|
@omajid do you know the above? Or are we not testing that? |
Mostly this. The sos version of the test is much less exhaustive than the dotnet-dump version of the test. |
|
Related: #485 |
|
@omajid Are you able to find what line of code in DacStackReferenceWalker::GCEnumCallbackSOS is faulting in? Or potential range of lines? That would go a long way towards narrowing it down. As an odd coincidence, I'll be working on that function for a perf issue next week. If I knew what was crashing here I might be able to take a look at this issue while working on the perf problem. Thanks! |
|
So the big question here is why isn't the catch block handling this? DacStackReferenceWalker::GetCount is wrapped in an SOS enter/leave: https://github.com/dotnet/runtime/blob/main/src/coreclr/debug/daccess/daccess.cpp#L7859-L7873 Which is defined here: https://github.com/dotnet/runtime/blob/main/src/coreclr/debug/daccess/dacimpl.h#L3984-L4004 We should be hitting that Obviously it's not good that something is causing the underlying crash (I'm working on a fix in .Net 8), but regardless, this should have manifested as a failed function call and not in bringing down the debugger. |
|
Ok, after digging in deeper here, it looks like this is unrelated to the underlying issues in DacStackReferenceWalker/DacHandleWalker. @tommcdon: Who is the right person to assign this issue? I believe this is an arm64 dac-ization issue. Since it's a dac-ization/stackwalking issue on arm64 (instead of an issue in the DacStackReferenceWalker), I'm not going to tackle this one. Also, I got to the bottom of this:
Unlike Windows, we don't attempt to swallow SIGSEGV issues. So the SIGSEGV crashing us is expected, but the underlying SIGSEGV isn't expected...and is likely a dac-ization problem. |
|
Let's check this again when .Net 8 preview 4 ships. It's possible that some of our previous fixes in this area might have resolved the issue. |
|
There are also crashes when using lldb sos |
|
@tdms, what issues are you seeing? Is there any repro that can be shared? Is it the same shell script that was shared before? |
|
Running this script should reproduce the gcroot issue: https://github.com/redhat-developer/dotnet-regular-tests/blob/main/debugging-sos-lldb-via-core/test.sh. |
|
@hoyosjs - any additional thoughts based on Tom's repro script? |
|
I haven't taken a look at this particular one, but I have 2 bugs in the 8 queue that might explain this. |
|
I'm currently investigating. |
Faulted in DAC because the HelperMethodFrame's REGDISPLAY CurrentContextPointers were not initialized correctly. Fixes issue dotnet/diagnostics#3726
Faulted in DAC because the HelperMethodFrame's REGDISPLAY CurrentContextPointers were not initialized correctly. Fixes issue dotnet/diagnostics#3726
Faulted in DAC because the HelperMethodFrame's REGDISPLAY CurrentContextPointers were not initialized correctly. Fixes issue dotnet/diagnostics#3726
|
Fixed in .NET 8 RC2 (September's release). |
|
@mikem8361 the PR mentions arm64. There is also a crash on x64. Do you expect it to be fixed as well? |
|
Ok, saw your new comment on the PR. x64 should be fixed by another change. Thanks! |
Faulted in DAC because the HelperMethodFrame's REGDISPLAY CurrentContextPointers were not initialized correctly. Fixes issue dotnet/diagnostics#3726 Co-authored-by: Mike McLaughlin <mikem@microsoft.com>
ghost
locked as resolved and limited conversation to collaborators
Description
I created a hello-world ASP.NET Core application (literally
dotnet new web; dotnet build; dotnet bin/Debug/net*/App.dll), then created a dump viadotnet-dump.I then used dotnet-dump analyze to examine it:
This crashes.
Backtrace from lldb:
The full test is here: https://github.com/redhat-developer/dotnet-regular-tests/blob/1b7774d6367751500e440a78909606cab0303a18/debugging-via-dotnet-dump/test.sh
Configuration
dotnet dump analyze <corefile>, thendsoand thengcroot -all objectwhere object is the first non-System.Objectfrom the output ofdso. In my case it's0000FFFFD8B0D708 0000ffbf65437050 System.Threading.Tasks.Task+SetOnInvokeMresdotnet info-->
Regression?
IIRC, this works on x64 without any issues, just fails on arm64. It was working on arm64 in a previous release of .NET as well, though I am not sure whether that was .NET 6 or .NET 7.
Other information
cc @tmds @aslicerh
The text was updated successfully, but these errors were encountered: