CODEWITHSUNDEEP
dockerasp.net-core.net-coreubuntu-18.04
matthewrk
matthewrk

Reputation: 687

Unable to run dotnet dump in 3.1 docker container - "Process 1 not running compatible .NET Core runtime"

After upgrading my previously very stable dotnet core app from 2.0 to 3.1 it started to experience a memory leak. I'm trying to grab a core dump to analyse what's using all the memory but have been running into multiple stumbling blocks trying to do that.

My app runs in a docker container based off of mcr.microsoft.com/dotnet/core/sdk:3.1 for build and mcr.microsoft.com/dotnet/core/aspnet:3.1-bionic for runtime.

For debug purposes I'm using mcr.microsoft.com/dotnet/core/sdk:3.1-bionic then installing the required tools:

dotnet tool install -g dotnet-dump
dotnet tool install -g dotnet-counters
dotnet tool install -g dotnet-trace

When I attempt to run dotnet-trace to grab the pid it returns a different pid each time:

root@499333cca890:/app# dotnet trace ps
      1290 dotnet     /usr/share/dotnet/dotnet

root@499333cca890:/app# dotnet trace ps
      1311 dotnet     /usr/share/dotnet/dotnet

root@499333cca890:/app# dotnet trace ps
      1332 dotnet     /usr/share/dotnet/dotnet

That could be the trace itself and its not picking up my app? the pid reported by ps aux is 1 (I assume this is a docker thing):

root@499333cca890:/app# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.4  7.7 21890008 158932 ?     Ssl  05:52   1:14 dotnet MyApp.dll

If I attempt to take a core dump via dotnet core dump collect -p 1 I get the following:

Process 1 not running compatible .NET Core runtime.

Here's the output from dotnet --info:

.NET Core SDK (reflecting any global.json):
 Version:   3.1.302
 Commit:    41faccf259

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  18.04
 OS Platform: Linux
 RID:         ubuntu.18.04-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.302/

Host (useful for support):
  Version: 3.1.6
  Commit:  3acd9b0cd1

.NET Core SDKs installed:
  3.1.302 [/usr/share/dotnet/sdk]

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

And here's the target framework from my csproj:

<TargetFramework>netcoreapp3.1</TargetFramework>

Locally I'm running macos as the docker host and setting privileged and enabling SYS_PTRACE:

 docker run -d --privileged --cap-add SYS_PTRACE [...]

Those options were my last discovery and I thought they would be the solution but still no luck. I'm assuming its something else along those lines that I'm missing? Other than that its just a 3.1 app running in the latest 3.1 sdk so I can't figure out why there'd be a problem there.

Upvotes: 3

Views: 4100

Answers (1)

matthewrk
matthewrk

Reputation: 687

By comparing my app line by line to a new dotnet web app project which didn't show the same behaviour I found the cause to be this line in my Program.cs Main() method:

CreateHostBuilder(args).Start()

Changing that to the following resolves the problem in accessing diagnostics, as well as the memory issue I was encountering:

CreateHostBuilder(args).Build().Run()

This is the default in a new dotnet core web app project so not sure where I picked up the use of .Start(). The difference appears to be that Run is asynchronous, Start ultimately calls the same methods but waits on the asynchronous task so my assumption is that it may block other tasks.

Upvotes: 2

Related Questions