clrmd: LinuxLiveDataReader.GetVersionInfo does not produce the correct answer
ClrMd 1.1.46104 (also reproduces on latest master), .NET Core 2.1 on Linux x64 (Ubuntu 18.04)
Unhandled Exception: System.ArgumentOutOfRangeException: Version's parameters must be greater than or equal to zero.
Parameter name: revision
at System.Version..ctor(Int32 major, Int32 minor, Int32 build, Int32 revision)
at Microsoft.Diagnostics.Runtime.Linux.LinuxLiveDataReader.ParseForVersion(String s)
at Microsoft.Diagnostics.Runtime.Linux.LinuxLiveDataReader.GetVersionInfo(UInt64 addr, VersionInfo& version)
at Microsoft.Diagnostics.Runtime.ModuleInfo.get_Version()
at Microsoft.Diagnostics.Runtime.DataTargetImpl.InitVersions()
at Microsoft.Diagnostics.Runtime.DataTargetImpl.get_ClrVersions()
at (my code)
This happens when using a self-contained deployment and the directory name is a GUID, separated with dashes, like “909B593B-4E9B-4294-AC28-FD5A369FA776”.
Looking at what’s happening in LinuxLiveDataReader.GetVersionInfo
, it’s trying to parse the directory name containing .so files as a version (and apparently accepts any hexadecimal numbers, too!) but this obviously doesn’t work for self-contained deployments: the directory name may be a valid version, but not the CLR version.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 21 (14 by maintainers)
dotnet-dump/SOSHosting has C# code that searches for the @(#)Version for the “eeversion” SOS command. This code is only used for libcoreclr.so.
https://github.com/dotnet/diagnostics/blob/7fef83c075965a10e25d3dec551ea6cca4ca8c83/src/SOS/SOS.Hosting/SOSHost.cs#L667 https://github.com/dotnet/diagnostics/blob/7fef83c075965a10e25d3dec551ea6cca4ca8c83/src/SOS/SOS.Hosting/SOSHost.cs#L764
Verified the string goes into “Heap”/“Mini” dumps from
dotnet-dump
.https://github.com/dotnet/diagnostics/blob/7fef83c075965a10e25d3dec551ea6cca4ca8c83/src/SOS/SOS.Hosting/SOSHost.cs#L768
@mikem8361 FYI the use of
ModuleInfo.FileSize
here is incorrect: the file size on disk is often smaller than the image span size in memory. It happens to work for libcoreclr.so.Test results of
LinuxLiveDataReader.GetVersionInfo
usingModuleInfo.FileSize
, corresponding to those in #349: