After upgrading to sys-libs/glibc-2.40-r6, certain applications started to crash. The kernel log shows messages like: traps: dreamm[10142] general protection fault ip:7f1f2562ea93 sp:7ffcc5c91488 error:0 in libc.so.6[7f1f255c6000+140000] traps: steam-runtime-s[10195] general protection fault ip:7fd100ac8a93 sp:7ffcfc78a888 error:0 in libc.so.6[7fd100a60000+140000] traps: srt-logger[10258] general protection fault ip:7f24988c81b3 sp:7ffd13d833d8 error:0 in libc.so.6[7f2498860000+140000] traps: steam-runtime-c[10278] general protection fault ip:7fe2820c81b3 sp:7fff84221d58 error:0 in libc.so.6[7fe282060000+140000] traps: srt-logger[10325] general protection fault ip:7fd308ec81b3 sp:7ffe414904d8 error:0 in libc.so.6[7fd308e60000+140000] traps: pressure-vessel[10345] general protection fault ip:7fda44ec81b3 sp:7ffc8da9af98 error:0 in libc.so.6[7fda44e60000+140000] traps: gldriverquery[10377] general protection fault ip:7fd9834c8a93 sp:7ffc7158d078 error:0 in libc.so.6[7fd983460000+140000] traps: vulkandriverque[10420] general protection fault ip:7fdeeb960a93 sp:7ffe2d7a6f38 error:0 in libc.so.6[7fdeeb8f8000+140000] Neither DREAMM nor Steam would start up. Those two are very unrelated applications, alike only in that both are distributed as precompiled binaries. Downgrading to sys-libs/glibc-2.40-r5 restored both applications to normal operation.
commit 32f431f17e3b4006707b4f24e15890a837c88e2e Author: Andreas K. Hüttel <dilfridge@gentoo.org> Date: Thu Dec 5 14:11:01 2024 +0100 sys-libs/glibc: keyword 2.40-r6 (patchlevel 6) Patchset changelog 2.40-5..2.40-6 744a774ec9 (HEAD -> gentoo/2.40, tag: gentoo/glibc-2.40-6, gentoo/gentoo/2.40) elf: handle addition overflow in _dl_find_object_update_1 [BZ #32245] 697cf525ce linux: sparc: Fix clone for LEON/sparcv8 (BZ 31394) 79d68dbb59 Mitigation for "clone on sparc might fail with -EFAULT for no valid reason" (bz 31394) 4c2cf259b2 elf: Change ldconfig auxcache magic number (bug 32231) 40833e2570 Make tst-strtod-underflow type-generic 42dceceb33 linux: Add support for getrandom vDSO 009f93ec10 sparc: Fix restartable syscalls (BZ 32173) c35c50fae0 support: Make support_process_state_wait return the found state Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> My fear would be the getrandom changes as the only really big thing in there, but that may not be it. What's at the location where it dies?
> > What's at the location where it dies? Probably hard to find out for precompiled binaries... Could you try running the binaries with strace please? What happens just before the crash?
(In reply to Andreas K. Hüttel from comment #2) > > > > What's at the location where it dies? > > Probably hard to find out for precompiled binaries... > We should be able to see where it dies in libc.so.
(In reply to Sam James from comment #1) > What's at the location where it dies? I'm not sure what address to pass to addr2line. If I subtract what I am guessing is the base load address of libc.so.6 from the instruction pointer at which the fault occurred, then I get 0x68a93. $ addr2line -e /usr/lib/debug/lib64/libc.so.6.debug 68a93 /var/tmp/portage/sys-libs/glibc-2.40-r6/work/glibc-2.40/stdio-common/vfprintf-internal.c:996 I'm not sure if that's right, though. What's the number after the plus sign inside the square brackets? If the base load address of libc.so.6 is actually the sum of those two numbers with the plus sign between them, then the instruction pointer is pointing to an address *before* the base load address of the library, which makes no sense to me. ---- On an entirely different tack, I get different results when I try to start telnet using the two versions of libc.so.6: $ LD_LIBRARY_PATH=/var/tmp/portage/sys-libs/glibc-2.40-r5/image/lib64 telnet telnet> (i.e., it's fine) $ LD_LIBRARY_PATH=/var/tmp/portage/sys-libs/glibc-2.40-r6/image/lib64 telnet telnet: error while loading shared libraries: __vdso_gettimeofday: invalid mode for dlopen(): Invalid argument Highly suspect, given that the -r6 patchset touches vDSO stuff. Some programs just crash outright: $ LD_LIBRARY_PATH=/var/tmp/portage/sys-libs/glibc-2.40-r5/image/lib64 nl <<<Hello 1 Hello $ LD_LIBRARY_PATH=/var/tmp/portage/sys-libs/glibc-2.40-r6/image/lib64 nl <<<Hello Segmentation fault For that segfault, the kernel log reports: nl[2483]: segfault at 2 ip 0000000000000002 sp 00007ffee26b6388 error 14 in nl[556210ee3000+2000] likely on CPU 13 (core 6, socket 0) Code: Unable to access opcode bytes at 0xffffffffffffffd8.
(In reply to Matt Whitlock from comment #4) > invalid mode for dlopen(): Invalid argument That might be a red herring. It works fine if I explicitly invoke the dynamic linker from the newer version of glibc: $ LD_LIBRARY_PATH=/var/tmp/portage/sys-libs/glibc-2.40-r6/image/lib64 /lib64/ld-linux-x86-64.so.2 /usr/bin/telnet /usr/bin/telnet: error while loading shared libraries: __vdso_gettimeofday: invalid mode for dlopen(): Invalid argument $ LD_LIBRARY_PATH=/var/tmp/portage/sys-libs/glibc-2.40-r6/image/lib64 /var/tmp/portage/sys-libs/glibc-2.40-r6/image/lib64/ld-linux-x86-64.so.2 /usr/bin/telnet telnet> So maybe the problem really is in vfprintf-internal.c…
> > On an entirely different tack, I get different results when I try to start > telnet using the two versions of libc.so.6: > > $ LD_LIBRARY_PATH=/var/tmp/portage/sys-libs/glibc-2.40-r5/image/lib64 telnet > telnet> > (i.e., it's fine) > > $ LD_LIBRARY_PATH=/var/tmp/portage/sys-libs/glibc-2.40-r6/image/lib64 telnet > telnet: error while loading shared libraries: __vdso_gettimeofday: invalid > mode for dlopen(): Invalid argument Not sure if this is safe from mixing installed and non-installed libraries. In any case, > > Highly suspect, given that the -r6 patchset touches vDSO stuff. Yes. This+dlopen In any case, please try strace with a few of these programs to see what the last syscalls are.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=44d480aeb9b3f5b7d724a72cd7f97ec87d978f37 commit 44d480aeb9b3f5b7d724a72cd7f97ec87d978f37 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2024-12-06 15:27:48 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2024-12-06 15:28:31 +0000 sys-libs/glibc: patchlevel 7, the only change is that the getrandom vDSO is reverted Bug: https://bugs.gentoo.org/945967 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> sys-libs/glibc/Manifest | 1 + sys-libs/glibc/glibc-2.40-r7.ebuild | 1751 +++++++++++++++++++++++++++++++++++ 2 files changed, 1752 insertions(+)
Please also try -r7, no keywords so far
I think I know what happened, and I think my bug report is INVALID. I run DREAMM and Steam using a secondary user (because I don't trust opaque binaries to run as my usual user), and that secondary user has an LD_LIBRARY_PATH defined in its user profile so that Steam can find the 32-bit libraries that I emerged into a subtree sysroot (to keep them segregated from my real system root). That LD_LIBRARY_PATH contains glibc-2.40-r5, but I was using the dynamic linker from glibc-2.40-r6 since that's what was in the system root. Had I upgraded the glibc in the subtree, I am guessing I would have resolved my issue. I will try that now.
That was it. I'm very sorry for the false alarm. Patch level 7 can be reverted.
