clru command in lldb fails to work

[omajid]

Description

dotnet-sos version '5.0.160202' has a regression in the clru sos command.

Previous versions were working correctly, but a recent update makes it fail against .NET Core 5.0.102 and 3.1.111.

Here's an example lldb session that fails:

Added Microsoft public symbol server
(lldb) target create --core "coredump.72457"
Core file '/home/dotnet/dotnet3.1/tests/workdir/dotnet-regular-tests/debugging-sos-lldb-via-core/TestDir/coredump.72457' (x86_64) was loaded.
(lldb) ip2md 00007f2df81d986e
MethodDesc:   00007f2df91aadb0
Method Name:          ILStubClass.IL_STUB_PInvoke(System.Runtime.InteropServices.SafeHandle, Byte*, Int32)
Class:                00007f2df8e29ca0
MethodTable:          00007f2df8e29d08
mdToken:              0000000006000000
Module:               00007f2df831b828
IsJitted:             yes
Current CodeAddr:     00007f2df81d97d0
Version History:
  ILCodeVersion:      0000000000000000
  ReJIT ID:           0
  IL Addr:            0000000000000000
     CodeAddr:           00007f2df81d97d0  (Optimized)
     NativeCodeVersion:  0000000000000000
(lldb) clru 00007f2df81d986e
Normal JIT generated code
ILStubClass.IL_STUB_PInvoke(System.Runtime.InteropServices.SafeHandle, Byte*, Int32)
Unknown error in reading function IL
ilAddr is 0000000000000000
u 00007f2df81d986e  failed

Here is a test script that runs through a number of sos commands:https://github.com/redhat-developer/dotnet-regular-tests/blob/c05ff0d1cbf6123640f6993f93b83fb78f7e25aa/debugging-sos-lldb-via-core/test.sh

It started failing with the above error this week.

Configuration

• Is this related to a specific tool?

• Yes, dotnet-sos

• What OS and version, and what distro if applicable?
  • I am seeing this on Linux on the RHEL 8.4 development branch
  • This might even be a bug in lldb?
• What is the architecture (x64, x86, ARM, ARM64)?

• x64 (aka x86_64, amd64)

• Are you running in any particular type of environment? (e.g. Containers, a cloud scenario, app you are trying to target is a different user)
  • I can reproduce the error locally within a VM with a fresh user
• Is it a self-contained published application?
  • No, this is basically: dotnet new web && dotnet run && dotnet dump; lldb
• What's the output of dotnet info

$ dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.1.111
 Commit:    a9538e031d

Runtime Environment:
 OS Name:     rhel
 OS Version:  8
 OS Platform: Linux
 RID:         rhel.8-x64
 Base Path:   /usr/lib64/dotnet/sdk/3.1.111/

Host (useful for support):
  Version: 3.1.11
  Commit:  f5eceb8105

.NET Core SDKs installed:
  3.1.111 [/usr/lib64/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.1.11 [/usr/lib64/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.11 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

Regression?

Yes. This was working with RHEL 8.3 with .NET Core releases (5.0.100, 3.1.110), as late as December last year.

The package versions, if that's relevant:

$ rpm -qa | grep -E 'lldb|clang|dotnet|gcc|glibc' | sort -u
clang-11.0.0-0.2.rc2.module+el8.4.0+8195+484edabc.x86_64
clang-devel-11.0.0-0.2.rc2.module+el8.4.0+8195+484edabc.x86_64
clang-libs-11.0.0-0.2.rc2.module+el8.4.0+8195+484edabc.x86_64
clang-tools-extra-11.0.0-0.2.rc2.module+el8.4.0+8195+484edabc.x86_64
dotnet-5.0.102-2.el8.x86_64
dotnet-apphost-pack-5.0-5.0.2-2.el8.x86_64
dotnet-host-5.0.2-2.el8.x86_64
dotnet-hostfxr-5.0-5.0.2-2.el8.x86_64
dotnet-runtime-5.0-5.0.2-2.el8.x86_64
dotnet-sdk-5.0-5.0.102-2.el8.x86_64
dotnet-targeting-pack-5.0-5.0.2-2.el8.x86_64
dotnet-templates-5.0-5.0.102-2.el8.x86_64
gcc-8.4.1-1.el8.x86_64
gcc-c++-8.4.1-1.el8.x86_64
glibc-2.28-141.el8.x86_64
glibc-common-2.28-141.el8.x86_64
glibc-devel-2.28-141.el8.x86_64
glibc-headers-2.28-141.el8.x86_64
glibc-langpack-en-2.28-141.el8.x86_64
libgcc-8.4.1-1.el8.x86_64
lldb-11.0.0-0.1.rc2.module+el8.4.0+8195+484edabc.x86_64
lldb-devel-11.0.0-0.1.rc2.module+el8.4.0+8195+484edabc.x86_64
python3-lldb-11.0.0-0.1.rc2.module+el8.4.0+8195+484edabc.x86_64

[omajid]

@tmds reported this was failing with the Microsoft SDK too: https://github.com/dotnet/source-build/issues/1938#issuecomment-738658338

[omajid]

Oh, I can reproduce on Fedora 33 as well:

Added Microsoft public symbol server
(lldb) target create --core "coredump.18718"
Core file '/home/omajid/devel/dotnet-regular-tests/debugging-sos-lldb-via-core/TestDir/coredump.18718' (x86_64) was loaded.

(lldb) clru 00007fe46f7194ee
Normal JIT generated code
ILStubClass.IL_STUB_PInvoke(System.Runtime.InteropServices.SafeHandle, Byte*, Int32)
Unknown error in reading function IL
ilAddr is 0000000000000000
u 00007fe46f7194ee  failed

$ dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.1.111
 Commit:    a9538e031d

Runtime Environment:
 OS Name:     fedora
 OS Version:  33
 OS Platform: Linux
 RID:         fedora.33-x64
 Base Path:   /usr/lib64/dotnet/sdk/3.1.111/

Host (useful for support):
  Version: 3.1.11
  Commit:  f5eceb8105

.NET Core SDKs installed:
  3.1.111 [/usr/lib64/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.1.11 [/usr/lib64/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.11 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

My current system packages, including .NET Core 3.1.111 (built using source-build):

$ rpm -qa | grep -E 'lldb|clang|dotnet|gcc|glibc|dotnet' | sort -u
clang-11.0.0-2.fc33.x86_64
clang-devel-11.0.0-2.fc33.x86_64
clang-libs-11.0.0-2.fc33.x86_64
clang-tools-extra-11.0.0-2.fc33.x86_64
dotnet-apphost-pack-3.1-3.1.11-1.fc33.x86_64
dotnet-build-reference-packages-0-7.20200608gitcd5a8c6.fc33.x86_64
dotnet-host-3.1.11-1.fc33.x86_64
dotnet-hostfxr-3.1-3.1.11-1.fc33.x86_64
dotnet-runtime-3.1-3.1.11-1.fc33.x86_64
dotnet-sdk-3.1-3.1.111-1.fc33.x86_64
dotnet-sdk-3.1-source-built-artifacts-3.1.110-1.fc33.x86_64
dotnet-targeting-pack-3.1-3.1.11-1.fc33.x86_64
dotnet-templates-3.1-3.1.111-1.fc33.x86_64
gcc-10.2.1-9.fc33.x86_64
gcc-c++-10.2.1-9.fc33.x86_64
gcc-gdb-plugin-10.2.1-9.fc33.x86_64
glibc-2.32-3.fc33.x86_64
glibc-all-langpacks-2.32-3.fc33.x86_64
glibc-common-2.32-3.fc33.x86_64
glibc-devel-2.32-3.fc33.x86_64
glibc-headers-x86-2.32-3.fc33.noarch
glibc-langpack-en-2.32-3.fc33.x86_64
libgcc-10.2.1-9.fc33.x86_64
lldb-11.0.0-1.fc33.x86_64
lldb-devel-11.0.0-1.fc33.x86_64
python3-lldb-11.0.0-1.fc33.x86_64
texlive-sclang-prettifier-svn35087.0.1-34.fc33.noarch

[jakobbotsch]

Just ran into this one in .NET 9 on Windows as well. Looks like !U doesn't work for IL stubs?