[Bug 2143357] [NEW] dotnet-runtime-10.0 crashes intermittently (0x80131506) due to system libunwind 1.8.1 incompatibility

Ahmad Bitar 2143357 at bugs.launchpad.net
Thu Mar 5 20:56:17 UTC 2026


Public bug reported:

## Summary

The Ubuntu source-built dotnet-runtime-10.0 (10.0.3-0ubuntu1~25.10.1)
intermittently crashes with "Fatal error. Internal CLR error.
(0x80131506)" during parallel MSBuild operations on Ubuntu 25.10
(questing).

## Root Cause

Ubuntu's source-built .NET 10 links libcoreclr.so against the system
libunwind (libunwind8 1.8.1-0.1ubuntu1):

  $ ldd /usr/lib/dotnet/shared/Microsoft.NETCore.App/10.0.3/libcoreclr.so | grep unwind
      libunwind-x86_64.so.8 => /lib/x86_64-linux-gnu/libunwind-x86_64.so.8
      libunwind.so.8 => /lib/x86_64-linux-gnu/libunwind.so.8

libunwind 1.8.x has known incompatibilities with .NET's CLR stack
unwinding, specifically in dwarf_find_unwind_table
(Gfind_unwind_table.c) where text segment matching and load_base
calculation changed between 1.6.x and 1.8.x. This breaks unwinding
through ReadyToRun (R2R) pre-compiled assemblies, which are PE-format
files memory-mapped on Linux (not ELF).

Microsoft's official .NET SDK (from dotnet-install.sh) does NOT link to
any external libunwind — libcoreclr.so uses its own built-in DWARF
unwinder and does not crash.

## Crash Chain

1. MSBuild spawns parallel out-of-proc worker nodes via Unix domain sockets
2. Socket.DoConnect throws SocketException (EADDRNOTAVAIL)
3. CLR exception dispatch calls PAL_VirtualUnwind → libunwind's unw_step()
4. unw_step() fails on ReadyToRun frame (PE file, not ELF)
5. SoftwareExceptionFrame::Init calls EEPOLICY_HANDLE_FATAL_ERROR(COR_E_EXECUTIONENGINE)
6. Process terminates with SIGABRT

## How to Reproduce

On Ubuntu 25.10 with apt-installed dotnet-sdk-10.0:

  dotnet new blazor -o /tmp/test-crash
  cd /tmp/test-crash
  for i in $(seq 1 20); do
      dotnet clean -v q 2>/dev/null
      dotnet build 2>&1 || echo "CRASH on iteration $i"
  done

The crash occurs intermittently (~1 in 5-10 clean builds). Using -m:1
avoids it.

## Environment

- Ubuntu 25.10 (questing), kernel 6.17.0-14-generic
- dotnet-runtime-10.0: 10.0.3-0ubuntu1~25.10.1
- dotnet-sdk-10.0: 10.0.103-0ubuntu1~25.10.1
- libunwind8: 1.8.1-0.1ubuntu1
- Architecture: amd64

## Workaround

Install Microsoft's official .NET SDK via dotnet-install.sh instead of
Ubuntu's apt package. Microsoft's build does not link to system
libunwind.

## Related Issues

- https://github.com/dotnet/runtime/issues/97343 (libunwind 1.8.0 broke remote unwind)
- https://github.com/dotnet/runtime/issues/111855 (createdump crashes with system libunwind 1.8.0)
- https://bugs.launchpad.net/ubuntu/+source/dotnet7/+bug/2065178 (same class of issue on dotnet7)

## Suggested Fix

Either:
1. Patch dotnet10 source-build to bundle its own libunwind (like Microsoft's SDK), OR
2. Patch libunwind 1.8.1 with upstream fixes for .NET compatibility

** Affects: dotnet10 (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to dotnet10 in Ubuntu.
https://bugs.launchpad.net/bugs/2143357

Title:
  dotnet-runtime-10.0 crashes intermittently (0x80131506) due to system
  libunwind 1.8.1 incompatibility

Status in dotnet10 package in Ubuntu:
  New

Bug description:
  ## Summary

  The Ubuntu source-built dotnet-runtime-10.0 (10.0.3-0ubuntu1~25.10.1)
  intermittently crashes with "Fatal error. Internal CLR error.
  (0x80131506)" during parallel MSBuild operations on Ubuntu 25.10
  (questing).

  ## Root Cause

  Ubuntu's source-built .NET 10 links libcoreclr.so against the system
  libunwind (libunwind8 1.8.1-0.1ubuntu1):

    $ ldd /usr/lib/dotnet/shared/Microsoft.NETCore.App/10.0.3/libcoreclr.so | grep unwind
        libunwind-x86_64.so.8 => /lib/x86_64-linux-gnu/libunwind-x86_64.so.8
        libunwind.so.8 => /lib/x86_64-linux-gnu/libunwind.so.8

  libunwind 1.8.x has known incompatibilities with .NET's CLR stack
  unwinding, specifically in dwarf_find_unwind_table
  (Gfind_unwind_table.c) where text segment matching and load_base
  calculation changed between 1.6.x and 1.8.x. This breaks unwinding
  through ReadyToRun (R2R) pre-compiled assemblies, which are PE-format
  files memory-mapped on Linux (not ELF).

  Microsoft's official .NET SDK (from dotnet-install.sh) does NOT link
  to any external libunwind — libcoreclr.so uses its own built-in DWARF
  unwinder and does not crash.

  ## Crash Chain

  1. MSBuild spawns parallel out-of-proc worker nodes via Unix domain sockets
  2. Socket.DoConnect throws SocketException (EADDRNOTAVAIL)
  3. CLR exception dispatch calls PAL_VirtualUnwind → libunwind's unw_step()
  4. unw_step() fails on ReadyToRun frame (PE file, not ELF)
  5. SoftwareExceptionFrame::Init calls EEPOLICY_HANDLE_FATAL_ERROR(COR_E_EXECUTIONENGINE)
  6. Process terminates with SIGABRT

  ## How to Reproduce

  On Ubuntu 25.10 with apt-installed dotnet-sdk-10.0:

    dotnet new blazor -o /tmp/test-crash
    cd /tmp/test-crash
    for i in $(seq 1 20); do
        dotnet clean -v q 2>/dev/null
        dotnet build 2>&1 || echo "CRASH on iteration $i"
    done

  The crash occurs intermittently (~1 in 5-10 clean builds). Using -m:1
  avoids it.

  ## Environment

  - Ubuntu 25.10 (questing), kernel 6.17.0-14-generic
  - dotnet-runtime-10.0: 10.0.3-0ubuntu1~25.10.1
  - dotnet-sdk-10.0: 10.0.103-0ubuntu1~25.10.1
  - libunwind8: 1.8.1-0.1ubuntu1
  - Architecture: amd64

  ## Workaround

  Install Microsoft's official .NET SDK via dotnet-install.sh instead of
  Ubuntu's apt package. Microsoft's build does not link to system
  libunwind.

  ## Related Issues

  - https://github.com/dotnet/runtime/issues/97343 (libunwind 1.8.0 broke remote unwind)
  - https://github.com/dotnet/runtime/issues/111855 (createdump crashes with system libunwind 1.8.0)
  - https://bugs.launchpad.net/ubuntu/+source/dotnet7/+bug/2065178 (same class of issue on dotnet7)

  ## Suggested Fix

  Either:
  1. Patch dotnet10 source-build to bundle its own libunwind (like Microsoft's SDK), OR
  2. Patch libunwind 1.8.1 with upstream fixes for .NET compatibility

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dotnet10/+bug/2143357/+subscriptions




More information about the foundations-bugs mailing list