nxtn
commented
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
Open ppekrol opened 3 years ago
nxtn
commented
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
ppekrol
commented
3 years ago 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?
leculver
commented
3 years ago 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.
mikem8361
commented
3 years ago dotnet-dump/SOS will need it over the next few months. I may have some time to implement it over the holidays.
leculver
commented
3 years ago That works too. =)
leculver
commented
3 years ago @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.
ppekrol
commented
3 years ago 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.
AndreGleichner
commented
2 years ago It now also fails with .Net 6 on Windows. Single file apps in .Net 6 are statically linked to the clr on Windows too.
ppekrol
commented
2 years ago Hi @leculver
Any plans to support this?
leculver
commented
2 years ago 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.
leculver
commented
2 years ago I will double check the linux-part of this issue. The linked bug is only for the windows side of things.
ayende
commented
2 years ago 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.
ppekrol
commented
1 year ago 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.dllmodule has a path and it is in temp (self-extract feature of single file applications).Linux:
There is no
libcoreclr.soon 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
IncludeNativeLibrariesForSelfExtracttofalsebut it only affects my libraries, not the framework ones, so I do not think it matters here.Many thanks in advance for help!