Univention Bugzilla – Bug 55791
apt: merge patches to UCS UCS5.1 / 5.2
Last modified: 2024-05-02 16:32:05 CEST
The patches of apt have to be cherry-picked and rebased to (UCS 5.1 and) UCS 5.2.
we should consider dropping 20-Bug-51313-revert-thread_local-usage.patch by carefully checking if it is resolved. See Bug #51313 comment 12.
r19767 | Bug #55791: adjust patch hunks r19765 | Bug #55791: update hunks
The patches can be applied equally. diff -Nur ucs_5.0-0-ucs5.0-1/1.8.2.3/ ucs_5.2-0/2.6.1/ diff -Nur ucs_5.0-0-ucs5.0-1/1.8.2.3/ ucs_5.1-0/2.2.4/ So, this was left open because of comment 1. If the QA want to check it, ok. Otherwise we can think about it in the next UCS release.
(In reply to Jürn Brodersen from comment #12) > The lasso patch has fixed this: > lasso/5.0-0-0-ucs/2.6.0-2/10_expose_lasso_provider_verify_saml_signature.quilt I verified this again by installing the un-patched packages from Debian-10-Buster: ```console # apt install debian-archive-keyring # echo 'deb http://debian.knut.univention.de/ buster main' > /etc/apt/sources.list.d/deb.list # apt -qq update # apt install \ python3-ldap python3-apt \ {apt,libapt-inst2.0,libapt-pkg5.0}=1.8.2.3 \ cy2-saml \ liblasso3=2.6.0-2+deb10u1 # python3 -c "import _ldap; _ldap.get_option(_ldap.OPT_API_INFO); import apt" Segmentation fault (core dumped) ``` Just installing `liblasso3=2.6.0-2+deb10u1A~5.0.0.202106051546` fixes the SIGSEGV. ```console # echo 'deb http://deb.debian.org/debian-debug/ buster-debug main' > /etc/apt/sources.list.d/debug.list # echo 'deb-src http://debian.knut.univention.de/ buster main' > /etc/apt/sources.list.d/source.list # apt -qq update # apt install dpkg-dev gdb libc6-dbg python3-dbg liblasso3-dbgsym=2.6.0-2+deb10u1 {apt,libapt-inst2.0,libapt-pkg5.0}-dbgsym=1.8.2.3 # apt source apt=1.8.2.3 lasso=2.6.0-2+deb10u1 # gdb --args python3 -c "import _ldap; _ldap.get_option(_ldap.OPT_API_INFO); import apt" (gdb) dir apt-1.8.2.3 (gdb) dir lasso-2.6.0 (gdb) run … Program received signal SIGSEGV, Segmentation fault. std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (__str=<error reading variable: Cannot access memory at address 0x18>, this=0xa7cb40) at /usr/include/c++/8/ext/new_allocator.h:86 86 ~new_allocator() _GLIBCXX_USE_NOEXCEPT { } (gdb) bt #0 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (__str=<error reading variable: Cannot access memory at address 0x18>, this=0xa7cb40) at /usr/include/c++/8/ext/new_allocator.h:86 #1 GlobalError::Item::Item (this=0xa7cb40) at include/apt-pkg/error.h:311 #2 __gnu_cxx::new_allocator<std::_List_node<GlobalError::Item> >::construct<GlobalError::Item, GlobalError::Item const&> (this=0xa55540, __p=0xa7cb40) at /usr/include/c++/8/ext/new_allocator.h:136 #3 std::allocator_traits<std::allocator<std::_List_node<GlobalError::Item> > >::construct<GlobalError::Item, GlobalError::Item const&> (__a=..., __p=0xa7cb40) at /usr/include/c++/8/bits/alloc_traits.h:475 #4 std::__cxx11::list<GlobalError::Item, std::allocator<GlobalError::Item> >::_M_create_node<GlobalError::Item const&> (this=0xa55540) at /usr/include/c++/8/bits/stl_list.h:645 #5 std::__cxx11::list<GlobalError::Item, std::allocator<GlobalError::Item> >::_M_insert<GlobalError::Item const&> (__position=..., this=0xa55540) at /usr/include/c++/8/bits/stl_list.h:1903 #6 std::__cxx11::list<GlobalError::Item, std::allocator<GlobalError::Item> >::emplace_back<GlobalError::Item const&> (this=0xa55540) at /usr/include/c++/8/bits/stl_list.h:1235 #7 std::__cxx11::list<GlobalError::Item, std::allocator<GlobalError::Item> >::_M_initialize_dispatch<std::_List_const_iterator<GlobalError::Item> > (__last=..., __first=non-dereferenceable iterator for std::list, this=0xa55540) at /usr/include/c++/8/bits/stl_list.h:1832 #8 std::__cxx11::list<GlobalError::Item, std::allocator<GlobalError::Item> >::list (__x=std::__cxx11::list = {...}, this=0xa55540) at /usr/include/c++/8/bits/stl_list.h:746 #9 GlobalError::MsgStack::MsgStack (Pending=@0xa2d590: false, Messages=std::__cxx11::list = {...}, this=0xa55540) at include/apt-pkg/error.h:353 #10 __gnu_cxx::new_allocator<std::_List_node<GlobalError::MsgStack> >::construct<GlobalError::MsgStack, std::__cxx11::list<GlobalError::Item, std::allocator<GlobalError::Item> >&, bool&> (this=0xa2d598, __p=0xa55540) at /usr/include/c++/8/ext/new_allocator.h:136 #11 std::allocator_traits<std::allocator<std::_List_node<GlobalError::MsgStack> > >::construct<GlobalError::MsgStack, std::__cxx11::list<GlobalError::Item, std::allocator<GlobalError::Item> >&, bool&> (__a=..., __p=0xa55540) at /usr/include/c++/8/bits/alloc_traits.h:475 #12 std::__cxx11::list<GlobalError::MsgStack, std::allocator<GlobalError::MsgStack> >::_M_create_node<std::__cxx11::list<GlobalError::Item, std::allocator<GlobalError::Item> >&, bool&> (this=0xa2d598) at /usr/include/c++/8/bits/stl_list.h:645 #13 std::__cxx11::list<GlobalError::MsgStack, std::allocator<GlobalError::MsgStack> >::_M_insert<std::__cxx11::list<GlobalError::Item, std::allocator<GlobalError::Item> >&, bool&> (__position=..., this=0xa2d598) at /usr/include/c++/8/bits/stl_list.h:1903 #14 std::__cxx11::list<GlobalError::MsgStack, std::allocator<GlobalError::MsgStack> >::emplace_back<std::__cxx11::list<GlobalError::Item, std::allocator<GlobalError::Item> >&, bool&> (this=0xa2d598) at /usr/include/c++/8/bits/stl_list.h:1235 #15 GlobalError::PushToStack (this=0xa2d578) at ../apt-pkg/contrib/error.cc:224 #16 0x00007ffff6a31fa1 in pkgInitConfig (Cnf=...) at ../apt-pkg/init.cc:216 #17 0x00007ffff6ad8638 in ?? () from /usr/lib/python3/dist-packages/apt_pkg.cpython-37m-x86_64-linux-gnu.so … ``` The problem here is that Python uses `dlopen()` to dynamically load `libapt`, which is now using modern "thread local storage" (TLS) using C++ `std::thread`, but `libstdc++` does not seem to be fully initialized. Giving `LD_DEBUG=all` shows lots of difference between the original liblasso3 from Debian and UCS being used. - it mostly changed the order of symbols exported - UCS also exports `lasso_provider_verify_saml_signature` Interesting reads: - https://stackoverflow.com/questions/51209268/using-stdthread-in-a-library-loaded-with-dlopen-leads-to-a-sigsev - https://developers.redhat.com/articles/2021/12/17/why-glibc-234-removed-libpthread - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67791 > The apt patch could be dropped again: > apt/5.0-0-0-ucs/1.8.2.1/20-Bug-51313-revert-thread_local-usage.patch > > I'm still wondering if this was just a symptom or a bug in the error handling. I'm still unsure if the issue is really fixed; or if it is just fixed by accident: As reverting APT back to use pthread instead of TLS definitely fixes the issue, to me it looks like TLS is not initialized correctly in all cases and depends on other libraries like `lasso` doing it. TBC...
OK, so we keep 20-Bug-51313-revert-thread_local-usage.patch even though lasso/...2/10_expose_lasso_provider_verify_saml_signature.quilt fixes our problem, but we are not sure that TLS initialized correctly i every case, Reevaluate for next release.
* OK - 10_ignore_debian.patch * OK - 11-silence-warning.patch * OK - 13-use-ucs-keyring.patch * OK 20-Bug-51313-revert-thread_local-usage.patch