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

Launchpad Bug Tracker 2143357 at bugs.launchpad.net
Sun May 24 04:17:19 UTC 2026


[Expired for dotnet10 (Ubuntu) because there has been no activity for 60
days.]

** Changed in: dotnet10 (Ubuntu)
       Status: Incomplete => Expired

-- 
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:
  Expired

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