.NET Core apps and some dotnet commands freeze with no output on FreeBSD 12.0

[joperator]

I've published and run .NET Core apps on FreeBSD 11.2 with the .NET Core 3.0 SDKs for Windows and FreeBSD provided by the daily builds.
But I can't get it work on FreeBSD 12.0 because .NET Core apps just freeze with no output. Even dotnet commands like dotnet --help, --info and publish freeze with no output, whereas dotnet --list-sdks and --list-runtimes work as expected.

[janvorli]

CC: @wfurt

[wfurt]

Just to double-check: you tried both publishing self-contained app on windows as well as running the app with SDK on FreeBSD?
(and you installed dependency packages: pkg install icu libunwind bash krb5 lttng-ust)

you can try to set following variables

export DOTNET_CLI_TELEMETRY_OPTOUT=1 
export COMPlus_ZapDisable=1
export COMPlus_ReadyToRun=0
export COREHOST_TRACE=1 

first three may make some difference, last one simply enables some diagnostic output and that may show something interesting.

Another option may be:
truss -o trace.txt myAPp
That will track system calls (like strace on Linux) and again it can show where application is stuck)

[hjc4869]

Having the same issue on FreeBSD 12.0. output.txt is coreclr trace, and trace.txt is truss output (those SIGINT at the last lines were fired by me with Ctrl-C).

output.txt
trace.txt

[wfurt]

thanks. I did upgrade one of my systems and I can reproduce it easily. It seems like some problem with threading/locking. I don't know if this is binary compatibility or if it is related to some OS changes in 12.
I think next step would be getting PAL tests executed.
As the release happened mid December, we currently don't have any systems running 12.0.

[joperator]

Yes, I've published a self-contained app on Windows and tried to run it on FreeBSD, as well as tried to publish the app on FreeBSD again.
After setting the variables as described by @wfurt I got the output and trace similar to the one @hjc4869 had already posted.
Thanks for investigating.

[wfurt]

Can you please try this @joperator ?

LD_PRELOAD=/usr/lib/libpthread.so ./dotnet-3.x/dotnet --info

[joperator]

dotnet --info works as well as --help, --list-sdks and --list-runtimes. Publishing a self-contained app on Windows and running it on FreeBSD also works.
But if I try to publish a self-contained app on FreeBSD, I get the following exception: exception.txt
I also set LD_DEBUG=all, but that doesn't seem to have any effect.

[wfurt]

It seems like LD_DEBUG does not work when LD_PRELOAD is used as well ;(

[furt@daemon /tmp/dd]$ ldd /home/furt/dotnet-3.x/shared/Microsoft.NETCore.App/3.0.0-preview-27218-01/System.Security.Cryptography.Native.OpenSsl.so
/home/furt/dotnet-3.x/shared/Microsoft.NETCore.App/3.0.0-preview-27218-01/System.Security.Cryptography.Native.OpenSsl.so:
	libcrypto.so.8 => not found (0)
	libssl.so.8 => not found (0)
	libc.so.7 => /lib/libc.so.7 (0x800248000)

 [furt@daemon /tmp/dd]$ sudo pkg install  openssl-1.0.2q,1

[furt@daemon /tmp/dd]$ sudo ln -s  /usr/local/lib/libssl.so.9  /usr/local/lib/libssl.so.8
[furt@daemon /tmp/dd]$ sudo ln -s /usr/local/lib/libcrypto.so.9 /usr/local/lib/libcrypto.so.8

[furt@daemon /tmp/dd]$ LD_PRELOAD=/usr/lib/libpthread.so ./bin/Debug/netcoreapp3.0/freebsd-x64/publish/dd
Hello World!

That is not great but hopefully this will help unblocking your testing @joperator

It seems like we may need more build changes or perhaps split FreeBSD 11.x builds from 12.

Maybe @russellhadley or @josteink would have some suggestions how binary portability should work.

[joperator]

Yes, this allows me to publish a self-contained app on FreeBSD 12.0.
Thank you very much @wfurt.

[jasonpugsley]

I have not had an issue running the 3.0.0 SDK built on FreeBSD11 on FreeBSD12 or FreeBSD13.
I think this was the fix in core-setup #5072
A related issue was closed in corefx #40865 via #41794.
Unless this is still a problem for anyone this issue can be closed too.

[joperator]

This issue only seems to affect this .NET Core SDK, provided by the daily builds on December 18, 2019 with SDK version 3.0.100-preview-010021.
I haven't encountered this issue in newer .NET Core SDK versions provided by @wfurt, @jasonpugsley, or built by myself. So I also think that this issue can be closed now.