Fedora Account System
Red Hat Associate
Red Hat Customer
See the upstream bug report for details: https://github.com/matplotlib/matplotlib/issues/29976 The bug is fixed upstream in git, but the fix is not yet in a tagged release version. The fix is part of this PR: https://github.com/matplotlib/matplotlib/pull/31879 Reproducible: Always Steps to Reproduce: 1. Every time koji picks a ppc64le builder to build the python-metakernel package (a noarch package) the build fails due to segfault in the %check due to this matplotlib bug. https://koschei.fedoraproject.org/package/python-metakernel?collection=f43 https://koschei.fedoraproject.org/package/python-metakernel?collection=f44 https://koschei.fedoraproject.org/package/python-metakernel?collection=f45 https://koschei.fedoraproject.org/package/python-metakernel?collection=f46 Actual Results: Failing python-metakernel builds on ppc64le. Expected Results: Working python-metakernel builds on all architectures including ppc64le.
That issue just points to it being an external problem (mixed libc or other toolchain issue). The PR doesn't fix anything; it just removes the code path that might fail immediately on import, but any other thing that might raise a C++ exception might crash in the same way.
I've distilled it down to loading the following library (note that this is far down the chain of metakernel->jupyter_client->zeromq) that causes the problem: $ mock -r fedora-rawhide-ppc64le --install zeromq python3-matplotlib gdb $ mock -r fedora-rawhide-ppc64le --shell --enable-network # gdb python3 (gdb) r >>> from ctypes import cdll >>> lib = cdll.LoadLibrary('libzmq.so.5') >>> from matplotlib.ft2font import FT2Font Program received signal SIGSEGV, Segmentation fault. _ULppc64_dwarf_find_proc_info (as=0x0, ip=140737488344128, pi=0x7fffffffcf90, need_unwind_info=need_unwind_info@entry=1, arg=0x0) at dwarf/Gfind_proc_info-lsb.c:807 807 ret = as->iterate_phdr_function (dwarf_callback, &cb_data); (gdb) bt full #0 _ULppc64_dwarf_find_proc_info (as=0x0, ip=140737488344128, pi=0x7fffffffcf90, need_unwind_info=need_unwind_info@entry=1, arg=0x0) at dwarf/Gfind_proc_info-lsb.c:807 #1 0x00007ffff654c060 in fetch_proc_info (c=c@entry=0x7fffffffcba0, ip=<optimized out>) at dwarf/Gparser.c:473 #2 0x00007ffff654d28c in _ULppc64_dwarf_make_proc_info (c=c@entry=0x7fffffffcba0) at dwarf/Gparser.c:1047 #3 0x00007ffff654d498 in _ULppc64_get_proc_info (cursor=0x7fffffffcba0, pi=pi@entry=0x7fffffffc550) at ppc/Gget_proc_info.c:35 #4 0x00007ffff654d7b0 in _Unwind_GetLanguageSpecificData (context=<optimized out>) at unwind/GetLanguageSpecificData.c:34 #5 0x00007ffff5f22e30 in __cxxabiv1::__gxx_personality_v0 (version=<optimized out>, actions=<optimized out>, exception_class=<optimized out>, ue_header=<optimized out>, context=<optimized out>) at ../../../../libstdc++-v3/libsupc++/eh_personality.cc:447 #6 0x00007ffff637e9c0 in _Unwind_RaiseException_Phase2 (exc=exc@entry=0x1001c9100, context=context@entry=0x7fffffffcba0, frames_p=frames_p@entry=0x7fffffffd410) at ../../../libgcc/unwind.inc:64 #7 0x00007ffff637f770 in _Unwind_Resume (exc=0x1001c9100) at ../../../libgcc/unwind.inc:242 #8 0x00007fffb00e0ab8 in ft2font__getattr__ (name=...) at ../src/ft2font_wrapper.cpp:1640 #9 0x00007fffb0103114 in pybind11::cpp_function::initialize<pybind11::object (*&)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >), pybind11::object, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, pybind11::name, pybind11::scope, pybind11::sibling>(pybind11::object (*&)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >), pybind11::object (*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >), pybind11::name const&, pybind11::scope const&, pybind11::sibling const&)::{lambda(pybind11::detail::function_call&)#1}::_FUN(pybind11::detail::function_call&) () at /usr/include/pybind11/cast.h:2195 ... If I load `libunwind.so.8` directly instead of `libzmq.so.5`, then it does not crash. But if I rebuild zeromq using `--without unwind`, then it also does not crash. So this has something to do with `libzmq` _with_ `libunwind` linked to it. Looking at the backtrace, we can see that we're in the C++ stdlib `__cxxabiv1::__gxx_personality_v0` but then go to `_Unwind_GetLanguageSpecificData` from `libunwind`. Based on the linked libunwind PR/commit, it seems that C++ exception handling should not be enabled in distros. If we look at the most recent build https://koji.fedoraproject.org/koji/buildinfo?buildID=2838927, then for x86_64, we have: > checking if C++ exception support should be built... no but on ppc64le, we have: > checking if C++ exception support should be built... yes That's because the spec doesn't explicitly enable or disable the feature and it's autodetected. So we should explicitly pass the flag to disable the C++ exception feature.
The dropped symbols are: -_Unwind_Backtrace -_Unwind_DeleteException -_Unwind_FindEnclosingFunction -_Unwind_ForcedUnwind -_Unwind_GetBSP -_Unwind_GetCFA -_Unwind_GetDataRelBase -_Unwind_GetGR -_Unwind_GetIP -_Unwind_GetIPInfo -_Unwind_GetLanguageSpecificData -_Unwind_GetRegionStart -_Unwind_GetTextRelBase -_Unwind_RaiseException -_Unwind_Resume -_Unwind_Resume_or_Rethrow -_Unwind_SetGR -_Unwind_SetIP _Unwind_GetBSP is not used in Fedora, and the rest are provided by libgcc_s as versioned symbols. It should be safe to configure with --disable-cxx-exceptions without an ABI transition.
I'm still waiting for a build to complete successfully. I've git a spec file change that results in the expected build configuration change.
I had to fix a bunch of s390x issues via backports to get things to build successfully. I'm going to backport this to older Fedora releases next week.
(In reply to Florian Weimer from comment #5) > I'm going to backport this to older Fedora releases next week. Ping.
FEDORA-2026-6657604f4e (libunwind-1.8.3-4.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-6657604f4e
FEDORA-2026-e537df8511 (libunwind-1.8.3-4.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-e537df8511
(In reply to Fedora Update System from comment #8) > FEDORA-2026-e537df8511 (libunwind-1.8.3-4.fc43) has been submitted as an > update to Fedora 43. > https://bodhi.fedoraproject.org/updates/FEDORA-2026-e537df8511 Thanks for the reminder. Builds done and Bodhi updates submitted.
FEDORA-2026-6657604f4e has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-6657604f4e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-6657604f4e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-e537df8511 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-e537df8511` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-e537df8511 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-6657604f4e (libunwind-1.8.3-4.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-e537df8511 (libunwind-1.8.3-4.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.