Runtime: .NET 5.0 Segmentation Fault - Marshal.SizeOf

[iamcarbon]

When updating to .NET 5.0 today and running on Linux (Ubuntu 20.04), we're getting a Segmentation fault (core dumped) error. Everything continues to work well using .netcoreapp3.1.

Are there any recommended tools that can help isolate the call before the SIGSEGV? I've tried running the app with gdb which provides the thread list.

I'll work on isolating this further and reproducing a minimal repo.

Here's how we're building and running the app.

publish ./src/App -f net5.0 -c release -r linux-x64 -o 

./App -> Segmentation fault (core dumped)

---

GDB output.

gdb ./App
(gdb)  run -d -L debug
Starting program: /var/apps/135/0.6.203/App -d -L debug
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6b30700 (LWP 12374)]
[New Thread 0x7ffff632f700 (LWP 12375)]
[New Thread 0x7ffff5b2e700 (LWP 12376)]
[New Thread 0x7ffff5324700 (LWP 12377)]
[New Thread 0x7ffff4adf700 (LWP 12378)]
[New Thread 0x7fffe7fff700 (LWP 12379)]
[New Thread 0x7ffff4095700 (LWP 12380)]
[New Thread 0x7fffe74dc700 (LWP 12381)]
[New Thread 0x7fff7d2ab700 (LWP 12382)]
[New Thread 0x7fffe711e700 (LWP 12383)]
[New Thread 0x7ffd291fa700 (LWP 12384)]
[New Thread 0x7fff7c598700 (LWP 12385)]
[New Thread 0x7ffd289f9700 (LWP 12386)]
[New Thread 0x7ffd0bfff700 (LWP 12387)]
[New Thread 0x7ffd0b7fe700 (LWP 12388)]
[New Thread 0x7ffd0affd700 (LWP 12389)]

Thread 1 "App" received signal SIGSEGV, Segmentation fault.

[hoyosjs]

A first approach would be setting the variables described here: https://github.com/dotnet/runtime/blob/master/docs/design/coreclr/botr/xplat-minidump-generation.md

Then you can load the dump in something like lldb (gdb doesn't really work for managed code out of the box). Following these instructions might give you a hint: https://github.com/dotnet/diagnostics/blob/master/documentation/debugging-coredump.md#launch-lldb-under-linux

Particularly bt all and clrstack -all -f can give you the stacks and you can see the stack and frame that caused the segmentation fault.

[iamcarbon]

@hoyosjs Thanks for the helpful debugging information! I was able to capture a stacktrace and isolate the problem.

This was caused by an external library that was calling Marshal.SizeOf over arbitrary types. Previously, this call was throwing a catchable exception. Certain managed types now throw a segfault.

problematic code

{
  return Marshal.SizeOf(marshalType);
}
catch  
{
  return null;
}

dumpstack

00007FFE2A09D780 00007eff4cd24dff [HelperMethodFrame_1OBJ: 00007ffe2a09d780] System.Runtime.InteropServices.Marshal.SizeOfHelper(System.Type, Boolean)
00007FFE2A09D8B0 00007EFED2AF71C2 System.Runtime.InteropServices.Marshal.SizeOf(System.Type)

Since Marshal is an unsafe API and was being used incorrectly, this issue can be closed.

[jkotas]

Marshal.SizeOf is not expected to crash like this. Could you please share some details about the type that this is crashing on?

[AaronRobinsonMSFT]

/cc @jkoritzinsky

[iamcarbon]

@jkotas Yep. I'll put together a minimal reproduction case the next few days.

[iamcarbon]

Here's a minimal reproduction case. This segfaults in 64 bit linux running on .NET5.0.

OK on Windows & .NETCOREAPP3.1.

using System;
using System.Runtime.InteropServices;

try
{
    _ = Marshal.SizeOf(typeof(byte[]));        
}
catch (Exception ex)
{
    // never called
    Console.WriteLine(ex.Message);
}

// never reached
Console.WriteLine("ok");