Crashing attempting to call `dumplog`

[AaronRobinsonMSFT]

Description

When calling dumplog log.txt on a .NET 9 Checked build, the lldb process crashes with the following output. Note that the target process doesn't crash.

(lldb) dumplog log.txt
Attempting to dump Stress log to file 'log.txt'
Writing to file: log.txt
Stress log in module 0x0000000103510000
Stress log address = 0x0000000103BDBC18
.......PLEASE submit a bug report to https://developer.apple.com/bug-reporting/ and include the crash backtrace.
Stack dump:
0.  Program arguments: /Library/Developer/CommandLineTools/usr/bin/lldb -p 89759
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  lldb                     0x00000001000f77dc llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56
1  lldb                     0x00000001000f6d38 llvm::sys::RunSignalHandlers() + 112
2  lldb                     0x00000001000f7e14 SignalHandler(int) + 304
3  libsystem_platform.dylib 0x0000000187989a24 _sigtramp + 56
4  libmscordaccore.dylib    0x0000000111d3b020 MethodTable::ValidateWithPossibleAV() + 44
5  libmscordaccore.dylib    0x0000000111db5f4c DacValidateMD(__DPtr<MethodDesc>) + 248
6  libmscordaccore.dylib    0x0000000111db87a8 ClrDataAccess::GetMethodDescData(unsigned long long, unsigned long long, DacpMethodDescData*, unsigned int, DacpReJitData*, unsigned int*) + 212
7  libsos.dylib             0x00000001118399bc IsMethodDesc(unsigned long) + 104
8  libsos.dylib             0x000000011181351c formatOutput(IDebugDataSpaces*, __sFILE*, char*, unsigned int, double, unsigned long, void**) + 1300
9  libsos.dylib             0x0000000111814044 StressLog::Dump(unsigned long, char const*, IDebugDataSpaces*) + 2216
10 libsos.dylib             0x000000011182455c DumpLog + 560
11 libsosplugin.dylib       0x00000001010682c8 sosCommand::DoExecute(lldb::SBDebugger, char**, lldb::SBCommandReturnObject&) + 316
12 LLDB                     0x00000001124ae430 CommandPluginInterfaceImplementation::DoExecute(lldb_private::Args&, lldb_private::CommandReturnObject&) + 268
13 LLDB                     0x000000011274dad0 lldb_private::CommandObjectParsed::Execute(char const*, lldb_private::CommandReturnObject&) + 656
14 LLDB                     0x000000011274475c lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&, bool) + 2024
15 LLDB                     0x0000000112747f9c lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&) + 828
16 LLDB                     0x000000011267f7c8 lldb_private::IOHandlerEditline::Run() + 304
17 LLDB                     0x00000001126640c4 lldb_private::Debugger::RunIOHandlers() + 140
18 LLDB                     0x0000000112749178 lldb_private::CommandInterpreter::RunCommandInterpreter(lldb_private::CommandInterpreterRunOptions&) + 196
19 LLDB                     0x00000001124c5798 lldb::SBDebugger::RunCommandInterpreter(bool, bool) + 124
20 lldb                     0x00000001000e82b8 Driver::MainLoop() + 2712
21 lldb                     0x00000001000e8d14 main + 2036
22 dyld                     0x00000001875d90e0 start + 2360
zsh: segmentation fault  lldb -p 89759

Configuration

macOS (Sonoma 14.2.1) arm64 Checked build of coreclr, 4b19d67aaa0c9c286b7cb575399445828e975245, running under corerun.

[mikem8361]

We fixed a few issues in DacValidateMD in .NET 9. Is this still reproducible?

[dotnet-policy-service[bot]]

Hi @AaronRobinsonMSFT. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[dotnet-policy-service[bot]]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

[dotnet-policy-service[bot]]

Hi @AaronRobinsonMSFT. We are closing this issue due to inactivity. If you comment within 30 days it will automatically reopen. If you are not the author of this issue and you're facing the same problem, feel free to open a new issue referencing this one.