Runtime: Segmentation Fault on .NET 5 build for standalone for ARM

[shadowfox87]

Description

This bug is reproduceable on any version of .NET 5 after preview 6.

1. Build a standalone executable for Linux ARM, and use the produce single file option
2. It will give segmentation fault at the point on your code you instantiate a new TcpListener class. It works fine if you try on windows x64.

This is the line at where you will see it:

_listener = new TcpListener(address, port);

If you use the TRIM within the produce single file, it misses some assemblies that are used for webclient (given the same settings from before). This won't work even when trying on windows x64.

Configuration

• Which version of .NET is the code running on?
  .NET 5 Preview 8 (can use any version after Preview 6)

• What OS and version, and what distro if applicable?
  Archlinux latest version

• What is the architecture (x64, x86, ARM, ARM64)?
  ARM

• Do you know whether it is specific to that configuration?
  It won't work on ARM but works fine on Windows x64 (but will fail if TRIM is used)

Regression?

• Did this work in a previous build or release of .NET Core, or from .NET Framework?
  Yes it worked on all versions before preview 7.

[joperezr]

cc: @eerhardt this sounds like we are missing an annotation on System.Net.Sockets causing us to trim things that we shouldn't be trimming.

[msftbot[bot]]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[joperezr]

if it is indeed a missing annotation, then we probably will want to take this for 5.0

[karelz]

@joperezr is it something we (Networking team) should help with?

[joperezr]

I don't think so, in dotnet 5 we formed a v-team that has been working on making sure our framework is linker-friendly so we've been adding annotations on the framework and I just want to make sure that this issue doesn't mean that we missed one. We can take a look.

[joperezr]

@shadowfox87 are you able to get a dump of that so that we can check the managed callstack to see what is the problem here? I tried reproing this using the Preview 8 bits on a RaspberryPi but didn't have any luck. This is the code that I tried:
c# class Program { static void Main(string[] args) { var listener = new TcpListener(IPAddress.Any, 8080); Console.WriteLine(listener.ToString()); } }

I published that for linux-arm and published it Trimmed and single file. I can validate that the linker is in fact running and trimming some assemblies. The result runs fine for me on my Raspberry Pi. Can you send more info regarding repro steps as well as a full code snippet of what you are doing to reproduce this issue?

[HKunogi]

If unmark the Produce single file, it stops giving the issue and works fine.
Also, if trim unused assemblies is marked, gives this issue:

[shadowfox87]

@joperezr I can confirm the answer above. If you need any further information, @HKunogi can answer.

[joperezr]

Can you confirm which version of the SDK are you using? to figure this out try running dotnet --list-sdks and dotnet --version as it may be that what you are hitting is already addressed by an annotation that was added later.

[joperezr]

Note that Trimming unused assemblies is in preview as noted in the screenshot above, so it is likely for things like this to happen. We will definitely investigate and fix if there is anything to address here but do note that this fix might come after 5.0

[joperezr]

cc: @vitek-karas @swaroop-sridhar @agocke

Even though trimming unused assemblies is in preview for dotnet 5, we may still want to investigate why when selecting to produce a single file this starts causing issues but when not doing so things work just fine. For this reason I'm marking this issue as 5.0 so that we investigate at least that bit now, while the overall trimming scenario for unused assemblies will still be in preview for 5.0.

[agocke]

The screenshot says TypeLoadException, but the bug says segfault. I'm not sure what we're looking at.

[joperezr]

If I understood correctly, the TypeLoadException only happens when they decide to trim their application given that we are likely missing an annotation somewhere causing the linker to strip out a method that is required at runtime. The segfault problem seems to be the one that happens only when they decide to publish as a single file, but seems to not happen when unchecking that, which is what we probably want to take a look at. @HKunogi to confirm if what I understood is correct.

[agocke]

Ah yes I missed the middle screenshot, thanks.

[HKunogi]

If I understood correctly, the TypeLoadException only happens when they decide to trim their application given that we are likely missing an annotation somewhere causing the linker to strip out a method that is required at runtime. The segfault problem seems to be the one that happens only when they decide to publish as a single file, but seems to not happen when unchecking that, which is what we probably want to take a look at. @HKunogi to confirm if what I understood is correct.

Yes, exactly that, about the version, its: 5.0.100-preview.8.20417.9

[vitek-karas]

Any kind of repro would help. I tried the trimming problem (TypeLoadException), but no luck - it seems to work fine for me.
I will try linux-arm once I have a machine to test it on.

[HKunogi]

Any kind of repro would help. I tried the trimming problem (TypeLoadException), but no luck - it seems to work fine for me.
I will try linux-arm once I have a machine to test it on.

When i run it on windows it works perfectly fine, the issue only happens at linux arm.

[eerhardt]

@HKunogi - looking at your screenshot, I see you are using Configuration = Release | x64

Is that intentional? Is there a reason your Architecture is set to x64 when you are trying to publish to an arm machine?

[eerhardt]

Also - I'm unable to reproduce this on my Raspberry Pi using a simple console app the just creates a new TcpListener. @HKunogi, if you point to a complete project that reproduces this error, that would really speed up the investigation.

[HKunogi]

@HKunogi - looking at your screenshot, I see you are using Configuration = Release | x64

Is that intentional? Is there a reason your Architecture is set to x64 when you are trying to publish to an arm machine?

Its just the name of the configuration, it is configured properly, after some more testing i found out that using <TrimMode>Link</TrimMode> at the csproj file, fix the assembly not found exception and the segmentation fault. For what i read the .net 5 uses defaultly the assembly-level trimming, but when i set it to that member-level trimming, it simply worked fine. (at least it started up fine, needs to have some runtime tests to make sure its not missing anything and crashing, but while using the assembly-level trimming it was ever crashing at startup, or when the trim box was unticked).

[agocke]

Dup of https://github.com/dotnet/runtime/issues/41609, should be fixed

[agocke]

My mistake, didn't notice this was on arm32, not ARM64. This may be fixed, but we would need to run on an arm32 device to confirm.

[vitek-karas]

It's possibly going to be fixed by https://github.com/dotnet/runtime/pull/42402.

[whatevergeek]

oh well... got #SegmentationFault when running 'dotnet new' using the latest #dotnet 5 linux arm64 sdk ... reverting back to dotnet_v5.0.100-preview.1.20111.5 ... will try again when a new arm64 version is released