Description of problem: zeromq as it is built in Fedora and and EPEL 8 includes libunwind. At least on rhel8.7 ppc64le this breaks C++ exception handling in certain cases. I believe the case is when an exception is thrown from an object that is dlopen'ed. The problem is that libunwind exports a symbol _Unwind_GetLanguageSpecificData which is also a symbol found in libgcc_s.so which is part of the C++ language support runtime in particular it is part of C++ exception handling. On ppc64le at least when libunwind's version of _Unwind_GetLanguageSpecificData gets called in place of the one in libgcc_s.so and it is looking for the LSDA for a library which is dlopen'ed, it cannot find it. This makes it so that the exception cannot be caught and the application aborts. A library should not export functions that are _[A-Z] because those are reserved for system libraries. ref: http://eel.is/c++draft/lex.name#3.1 It seems like the function that zeromq wants out of libunwind is dladdr() which is available in the normal libdl. Therefore, it seems like the easiest course of action would be to build zeromq disabling libunwind support. It looks like this can be done just by building zeromq without pulling in the libunwind dependency since the default configuration is for libunwind is "auto". Alternatively the configure script can be run with --disable-libunwind. Version-Release number of selected component (if applicable): zeromq-4.3.4-2.el8.src.rpm How reproducible: It is kind of tricky to reproduce it. Never the less I do have an example test case if it is required. Actual results: C++ exceptions thrown from dlopen'ed shared libraries are not caught on ppc64le if libzmq is loaded and the application aborts even though there is a suitable exception handler. Expected results: The C++ exception is caught. Additional info: The particular problem here is in the EPEL8 version of zeromq. However, removing libunwind from zeromq should probably be considered for the normal version as well.
Thanks for the contribution! Do not hesitate to write a pull request (on https://src.fedoraproject.org/rpms/zeromq/tree/epel8), as I may not have the opportunity to work on that package before a while.
Created attachment 1948802 [details] proposed patch I'm not really setup on pagure to be able create pull requests or test packages. The patch itself is pretty straight forward. Can you try this and I will try to figure out how to create pull requests for fedora.
FEDORA-EPEL-2023-8332829962 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-8332829962
FEDORA-EPEL-2023-69b98a0072 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-69b98a0072
In addition to EPEL updates (for EPEL 8 and EPEL 9, see above), there was a successful build on Rawhide too (https://koji.fedoraproject.org/koji/taskinfo?taskID=98441644) and an automatic update for Fedora 39 (https://bodhi.fedoraproject.org/updates/FEDORA-2023-abdab709ff).
FEDORA-EPEL-2023-8332829962 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-2023-8332829962 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2023-69b98a0072 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-69b98a0072 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Created attachment 1949665 [details] subsequent patch Just making it possible to build without libunwind ends up not satisfying the customer. They make an argument that it should default that way. So I flipped the logic of the build conditional. This is of course much more invasive because it could impact other users of zeromq. I'm not really sure how to asses the impact of that however having 2 unwinders in any C++ code is probably a bad idea without them being in different namespaces.
Another thing that I wanted to point out is in this patch I didn't update the Release. I didn't know if this warranted a separate release or if both of these together would be one release.
Created attachment 1949703 [details] epel8 patch This is an EPEL8 version of the patch. The non-packager mode of fedora continues to confuse me.
FEDORA-EPEL-2023-8332829962 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2023-69b98a0072 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.