Open ppekrol opened 3 years ago
FYI CoreCLR is statically linked into single-file apps on Unix platforms.
https://github.com/dotnet/designs/blob/main/accepted/2020/single-file/design.md
Interesting. That would explain a lot. @NextTurn do you know maybe if there is a workaround for that problem that we could apply at the moment?
Single file applications are not something I plan to support in the near future.
The primary concern is ongoing maintenance costs of keeping it working vs how many people are currently using the feature. If more people start using it (and asking for support in ClrMD) I may reconsider.
dotnet-dump/SOS will need it over the next few months. I may have some time to implement it over the holidays.
That works too. =)
@mikem8361 To be clear, the number 1 thing that needs to happen for single file is adding tests to ClrMD so it doesn't regress. The actual implementation of it I don't expect to be too difficult. The challenge is building a sensible repro program we can use that's single-file that the current tests on linux can build. If that problem is solved I'm not too worried about maintaining it.
I've tried bypassing the issue by loading the libcoreclr.so
using
[DllImport("libdl.so")]
private static extern IntPtr dlopen(string filename, int flags);
I see that the module now is detected properly after attaching, but unfortunately it fails during runtime creation with:
Microsoft.Diagnostics.Runtime.ClrDiagnosticsException: Failure loading DAC: CreateDacInstance failed 0x80131c4e
at Microsoft.Diagnostics.Runtime.DacLibrary..ctor(DataTarget dataTarget, String dacDll)
at Microsoft.Diagnostics.Runtime.DataTarget.ConstructRuntime(ClrInfo clrInfo, String dac)
at Microsoft.Diagnostics.Runtime.DataTarget.CreateRuntime(ClrInfo clrInfo, String dacFilename, Boolean ignoreMismatch)
at Microsoft.Diagnostics.Runtime.ClrInfo.CreateRuntime(String dacFilename, Boolean ignoreMismatch)
So I do not think this is the way to go with a workaround (or I'm missing something).
Anyway, @leculver the simplest .NET 5 console app fails after publishing using dotnet publish -c Release -r linux-x64 /p:PublishSingleFile=true
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
</Project>
public static void Main(string[] args)
{
using (var process = Process.GetCurrentProcess())
{
Console.WriteLine($"Hello World: {process.Id}");
Console.WriteLine("Press any key to close...");
}
Console.ReadLine();
}
and attaching to it using:
using (var dataTarget = DataTarget.AttachToProcess(processId, attachTimeout, AttachFlag.Passive))
{
var clrInfo = dataTarget.ClrVersions[0];
}
Hope that it helps.
It now also fails with .Net 6 on Windows. Single file apps in .Net 6 are statically linked to the clr on Windows too.
Hi @leculver
Any plans to support this?
AFAIK this is actually due to an issue with create-dump, not with ClrMD. See this issue: https://github.com/dotnet/diagnostics/issues/3065.
When I last debugged this, there was not enough data being placed into the crash dump for any debugger to make sense of single-file dumps (ClrMD included). I'm happy to take a closer look if you find that's not the case.
I will double check the linux-part of this issue. The linked bug is only for the windows side of things.
FWIW - we don't care that much about looking at a dump file. We want to be able to attach to a running process as the primary concern here.
I will double check the linux-part of this issue. The linked bug is only for the windows side of things.
Hi @leculver
Have you managed to take a peak? Is there a difference between reading a dump file or attaching to an existing process? As @ayende mentioned, we are more interested in attaching, we are using this to display the stacks of the process.
OS: Ubuntu 20.04 (works fine on Windows 10) ClrMD version: 1.x and 2.x .NET: 5.0.0
Code (1.x):
Ex:
Code (2.x):
From brief investigation I think that the issue is how ClrMD detects the runtime. It enumerates through modules and checks the file names there to determine the runtime, so I wrote a code that writes down the list of modules and here are the results:
Windows:
As you can see the
coreclr.dll
module has a path and it is in temp (self-extract feature of single file applications).Linux:
There is no
libcoreclr.so
on that list and this is essential to detect the runtime. Any ideas how I can workaround it? Can it be fixed (preferably in 1.x) ?Interesting is that my custom native library (that was embedded) is on that list:
librvnpal.linux.x64.so
. Not sure if this can be detected by path, we stumbled upon a similar issue with assemblies location and metadata reference creation when we moved to Single File Application and we ended up with following code: https://github.com/ravendb/ravendb/blob/4da999402a54591572e6ed74ce0fb1791f90bc83/src/Raven.Server/Documents/Indexes/Static/IndexCompiler.cs#L118-L124 Previously we were doing that directly via file path: https://github.com/ravendb/ravendb/blob/0c1f169b255f9e5ab5e3fa8fc6f90c4dafee7d69/src/Raven.Server/Documents/Indexes/Static/IndexCompiler.cs#L100 (which is string.Empty in Single File Applications)My app, that I want to attach to, is compiled using following command:
Tried to set
IncludeNativeLibrariesForSelfExtract
tofalse
but it only affects my libraries, not the framework ones, so I do not think it matters here.Many thanks in advance for help!