I'm pasting an email answer here so we keep track of all that has been discussed for this issue:
---- > Me and Dan have been working recently on a customer case reported as LP: #1915828. Turns out that some linker "magic" used inside libqb broke pacemaker (and potentially any package using QB_LOG_INIT_DATA from the library or even every packaged linked against libqb). I have checked libqb commits and: https://paste.ubuntu.com/p/vTdYJdC4Hc/ . I see that upstream added some options in configure.ac related to the linking issue, even quoting debian/ubuntu option to override libtool variable by force. There is also an existing test for the __attribute__((section("__verbose"))) breakage detection now (gcc_has_attribute_section_visible variable in configure.ac. > Dan found an ABI-compatible way of mitigating the problem by rebuilding pacemaker with the QB_KILL_ATTRIBUTE_SECTION defined. This strips the magic and makes pacemaker useful again. I see the mitigation (QB_KILL_ATTRIBUTE_SECTION) comes from: -- 32555d8 tests: add a script to generate callsite-heavy logging client… ...so as to evaluate use of resources. In particular, the intention here is to uncover the observable differences between the same logging code built with callsite section (default when available) and purposefully (overriding that default by force) without it. ... -- And they even added “tests/functional/log_callsite_bench_gen.py” to measure the impact of this mitigation. I’m particularly worried with: — Based on the above, we can conclude that leveraging the callsite section for logging as facilitated by the toolchain intrinsics is beneficial, especially for performance-critical applications (corosync being the showcase here). Therefore it's desired to struggle for retaining this nifty trick despite some troubles emerged with recent binutils releases (starting with 2.29) and the changed behaviour we relied on so far in respective ld.bfd linkers (as mentioned in preceding commits). That motive is immediately followed -- well, judging the impact fairly, actually outclassed -- with the intention to preserve binary compatibility (incl. continuous library support for callsite section offloading spread in the existing client space widely for quite some years already) to the utmost extent possible. -- I believe this will be accepted by the SRU team but this, for sure, has to be mentioned in the public bug. I would add to [regression potential] the fact that the logging mechanism would stir heap more often (commit log has even a time execution delta). Shouldn’t this bug also affect all the libqb0 rdepends ? I can see pacemaker, sbd, corosync and usbguard source packages. > The problem is (more details in comments #3-#5) some symbols disappear from the package. Those symbols doesn't seem to be used anywhere explicitly, but we were wondering if it's ok to just drop those symbols or maybe to implement a change in libqb to create dummy constructors (e.g. https://pastebin.canonical.com/p/Y4fk747YfK/) to ensure the symbols are available just in case. For the pacemaker fix I’ll let the SRU team to discuss whether they would like to have symbols (or not) the symbols in the new binary (after this fix). I don’t think those symbols are used elsewhere (from rdepends of libcrm* they would only be used by either pacemaker OR sbd). I think next step here is to offer a patch and ask for the SRU team input/review. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1915828 Title: pacemaker fails to release clustered filesystem dlm locks on failover To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1915828/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
