Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: libunwind-1.6.2-1.el9.aarch64 segfaults during stack unwinding on aarch64. This is triggered by tcmalloc (gperftools) which calls GetStackTrace via libunwind during allocator initialization. The crash happens during shared library loading (before main()), making affected binaries completely unusable on arm64. The bug is non-deterministic in that it depends on allocation patterns — some builds trigger it, others don't. It is 100% reproducible once triggered. EPEL10 already ships libunwind 1.8.0 which does not have this bug. Fedora 42+ ships 1.8.1+. Only epel9 is stuck on the broken 1.6.2. Impact: The Ceph project relies on EPEL9 for libunwind. This bug appears and disappears across Ceph releases as a side effect of unrelated code changes (any change in allocation patterns during startup can shift the tcmalloc sampling point). Affected versions include v18.2.4, v20.2.1; other versions like v19.2.3 and v20.2.0 happen to avoid it by luck. This was discussed over a year ago in the Ceph community with the conclusion that EPEL9 needs to be updated: - https://tracker.ceph.com/issues/67213#note-27 (Ken Dreyer from Red Hat confirmed the EPEL9 package needs to be updated) - https://tracker.ceph.com/issues/76967 (latest occurrence in v20.2.1) - https://github.com/rook/rook/issues/14502 (Rook/Kubernetes users affected) Reproducer: $ podman run --rm quay.io/ceph/ceph:v20 /usr/bin/rbd-mirror Segmentation fault (core dumped) Confirmed version: # rpm -q libunwind libunwind-1.6.2-1.el9.aarch64 Stack trace (from coredumpctl): #0 0x0000ffffbd1fb624 n/a (libunwind.so.8.0.1 + 0x3624) #1 0x0000ffffbd200ee8 n/a (libunwind.so.8.0.1 + 0x8ee8) #2 0x0000ffffbd200ee8 n/a (libunwind.so.8.0.1 + 0x8ee8) #3 0x0000ffffbe76c994 n/a (libtcmalloc.so.4.5.9 + 0x2e994) #4 0x0000ffffbe771ce0 n/a (libtcmalloc.so.4.5.9 + 0x33ce0) #5 0x0000ffffbe765498 n/a (libtcmalloc.so.4.5.9 + 0x27498) ... #19 0x0000ffffbecb5be4 n/a (ld-linux-aarch64.so.1 + 0x5be4) #20 0x0000ffffbecb5cec n/a (ld-linux-aarch64.so.1 + 0x5cec) #21 0x0000ffffbecc8248 n/a (ld-linux-aarch64.so.1 + 0x18248) Fix: The issue was fixed upstream in libunwind v1.7.0 and further hardened in v1.8.0: v1.7.0 (full diff_: https://github.com/libunwind/libunwind/compare/v1.6.2...v1.7.0): - Fix undefined behavior issues in aarch64 https://github.com/libunwind/libunwind/pull/414 - fix incorrect store in AArch64 getcontext https://github.com/libunwind/libunwind/pull/353 v1.8.0 (https://github.com/libunwind/libunwind/releases/tag/v1.8.0): - aarch64: unw_step() validates address before calling dwarf_get https://github.com/libunwind/libunwind/pull/494 - Improve unw_step fallback method on Aarch64 https://github.com/libunwind/libunwind/pull/571 - Further improvements to unw_step fallback method on AArch64 https://github.com/libunwind/libunwind/pull/638 EPEL10 already ships 1.8.0. Fedora 42+ ships 1.8.1+. Please update the epel9 branch to match.
Here's the EPEL 10 build of libunwind: https://koji.fedoraproject.org/koji/buildinfo?buildID=2556916 Maybe we can get fweimer to either build the EPEL 9 version, or allow us (the Ceph build team) to? In the mean time, I made an el9 COPR repo for libunwind (if it helps): https://copr.fedorainfracloud.org/coprs/tserlin/libunwind/ Thanks, Thomas
I've uolifted the epel9 branch to the epel10.2 version. I'm going to submit an update via Bodhi once the build finishes. In parallel, we are exploring giving the Ceph team packager access.
FEDORA-EPEL-2026-6dc6441d34 (libunwind-1.8.0-4.el9) has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-6dc6441d34
FEDORA-EPEL-2026-6dc6441d34 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-6dc6441d34 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2026-6dc6441d34 (libunwind-1.8.0-4.el9) has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.