runtime: Dotnet 'myApp.dll' hang in lttng running on arm32

Running a very framework dependent console application with the command ‘dotnet myapp.dll’ causes a hang running on a simple yocto image on an Rpi3 (arm32)

Running dotnet --info produces the expected output of

Version : 2.0.0 Build : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

but running any application including a very basic app that simply writes to the console completely hangs with zero output to the terminal.

Running with COREHOST_TRACE=1 produces similar output to what is seen running the app on another Linux machine but it hangs before the expected line “Property TRUSTED_PLATFORM_ASSEMBLIES = …”

The ‘installation’ has been from the binary release at https://dotnetcli.blob.core.windows.net/dotnet/Runtime/2.0.0/dotnet-runtime-2.0.0-linux-arm.tar.gz

The final few lines of output before hanging are

Considering entry [runtime.linux-arm.Microsoft.NETCore.DotNetHostPolicy/2.0.0/runtimes/linux-arm/native/libhostpolicy.so] and probe dir [/opt/dotnet/shared/Microsoft.NETCore.App/2.0.0] Local path query exists /opt/dotnet/shared/Microsoft.NETCore.App/2.0.0/libhostpolicy.so Probed deps json and matched '/opt/dotnet/shared/Microsoft.NETCore.App/2.0.0/libhostpolicy.so' The resolved JIT path is '/opt/dotnet/shared/Microsoft.NETCore.App/2.0.0/libclrjit.so' CoreCLR path = '/opt/dotnet/shared/Microsoft.NETCore.App/2.0.0/libcoreclr.so', CoreCLR dir = '/opt/dotnet/shared/Microsoft.NETCore.App/2.0.0/'

At this stage ctrl+c has no effect and the process needs to be killed to recover the terminal

The full output is attached along with the application

output.txt testApp.zip

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 27 (12 by maintainers)

Commits related to this issue

Most upvoted comments

https://github.com/pauldotknopf/meta-dotnet

It is entirely removed from the build in the coreclr project as well.

https://github.com/qmlnet/coreclr/commits/yocto-v2.1.401

However, I just realized that core-setup is grabbing libcoreclr from somewhere else (it still had dependency on lttng). This issue went un-noticed because I disabled the “auto dependency” feature of Yocto with SKIP_FILEDEPS_${PN} = "1".

I’m still working on a native Yocto build that entirely removes lttng. Maybe, if I can get core-setup using the actual libcoreclr, I can use the debug symbols to figure out why lttng is causing the issue in the first place!

This is all still a work-in-progress. Email me at pauldotknopf[at]gmail.com if you want to help. I’ve only got so much hair to turn grey… 😉