Your message dated Mon, 26 Sep 2022 08:57:46 +0200 with message-id <yzfnamtsh0riq...@aurel32.net> and subject line Re: Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected" has caused the Debian Bug report #1020559, regarding libc6: After upgrading libc6 expr is crashing with "stack smashing detected" to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1020559: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020559 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: libc6 Version: 2.34-8 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I upgraded libc6 to latest released 2.35-1 * What exactly did you do (or not do) that was effective (or ineffective)? After upgrade noticed autoreconf --version was failing with **stack smashing detected** message. But in general looks like triggered by expr command. From the coredumpctl got following Message: Process 85280 (expr) of user 1000 dumped core. Module linux-vdso.so.1 with build-id c35c947b072ff69b395cd326b83b24630f2c5065 Module ld-linux-x86-64.so.2 with build-id a03c3b14d371da908a3f22007b3f0c73d1f9f634 Module libc.so.6 with build-id ef3afb43092687d7fcc8167fabdee73f4a3287f1 Module libgmp.so.10 with build-id 25c73b398493c695a013a6d9d493a8316aac0fa0 Module expr with build-id b919757cbc30fbb64b14498222499d972fd80acd Stack trace of thread 85280: #0 0x00007fbfabc8983c n/a (libc.so.6 + 0x8983c) #1 0x00007fbfabc3da52 raise (libc.so.6 + 0x3da52) #2 0x00007fbfabc28469 abort (libc.so.6 + 0x28469) #3 0x00007fbfabc7dc18 n/a (libc.so.6 + 0x7dc18) #4 0x00007fbfabd18c62 __fortify_fail (libc.so.6 + 0x118c62) #5 0x00007fbfabd18c40 __stack_chk_fail (libc.so.6 + 0x118c40) #6 0x00007fbfabc8449d n/a (libc.so.6 + 0x8449d) #7 0x00007fbfac06c893 n/a (ld-linux-x86-64.so.2 + 0x20893) #8 0x00007fbfac067f2f n/a (ld-linux-x86-64.so.2 + 0x1bf2f) #9 0x00007fbfac069b21 n/a (ld-linux-x86-64.so.2 + 0x1db21) #10 0x00007fbfac068948 n/a (ld-linux-x86-64.so.2 + 0x1c948) ELF object binary architecture: AMD x86-64 Back trace from gdb #0 0x00007fbfabc8983c in ?? () from /usr/lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007fbfabc8983c in ?? () from /usr/lib/x86_64-linux-gnu/libc.so.6 #1 0x00007fbfabc3da52 in raise () from /usr/lib/x86_64-linux-gnu/libc.so.6 #2 0x00007fbfabc28469 in abort () from /usr/lib/x86_64-linux-gnu/libc.so.6 #3 0x00007fbfabc7dc18 in ?? () from /usr/lib/x86_64-linux-gnu/libc.so.6 #4 0x00007fbfabd18c62 in __fortify_fail () from /usr/lib/x86_64-linux-gnu/libc.so.6 #5 0x00007fbfabd18c40 in __stack_chk_fail () from /usr/lib/x86_64-linux-gnu/libc.so.6 #6 0x00007fbfabc8449d in ?? () from /usr/lib/x86_64-linux-gnu/libc.so.6 #7 0x00007fbfac06c893 in dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at ./elf/rtld.c:2562 #8 0x00007fbfac067f2f in _dl_sysdep_start (start_argptr=start_argptr@entry=0x7ffdc5baaa40, dl_main=dl_main@entry=0x7fbfac069db0 <dl_main>) at ../sysdeps/unix/sysv/linux/dl-sysdep.c:140 #9 0x00007fbfac069b21 in _dl_start_final (arg=0x7ffdc5baaa40) at ./elf/rtld.c:507 #10 _dl_start (arg=0x7ffdc5baaa40) at ./elf/rtld.c:596 #11 0x00007fbfac068948 in _start () from /lib64/ld-linux-x86-64.so.2 #12 0x0000000000000001 in ?? () #13 0x00007ffdc5bacd78 in ?? () #14 0x0000000000000000 in ?? () * What outcome did you expect instead? expr should not have crashed. I'm attaching the core file from the systemd-coredump. Also post this I downgraded libc6 to 2.34-8 from snapshots and no more crash is detected. If anything more is needed do let me know. Thanks and Regards Vasudev -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libc6 depends on: ii libgcc-s1 12.2.0-3 Versions of packages libc6 recommends: ii libidn2-0 2.3.3-1+b1 Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.79 pn glibc-doc <none> ii libc-l10n 2.35-1 ii libnss-nis 3.1-4 ii libnss-nisplus 1.3-4 ii locales 2.35-1 -- debconf information: glibc/upgrade: true glibc/restart-services: glibc/kernel-not-supported: * libraries/restart-without-asking: true glibc/disable-screensaver: glibc/restart-failed: glibc/kernel-too-old:
core.expr.1000.d5ff83e0fd69439497afd17511de3417.85280.1663923583000000.zst
Description: application/zstd
--- End Message ---
--- Begin Message ---Hi, On 2022-09-26 11:05, Vasudev Kamath wrote: > Aurelien Jarno <aurel...@aurel32.net> writes: > > > Hi, > > > > On 2022-09-26 09:45, Vasudev Kamath wrote: > >> And post removing /usr/lib version of libc it seems to work fine and no > >> crash is happening. > >> > >> └─(09:44:30 on master)──> expr > >> > >> 1 ↵ ──(Mon,Sep26)─┘ > >> expr: missing operand > >> Try 'expr --help' for more information. > >> ┌─(~/.emacs.d)─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────(vasudeva.sk@bhrigu:pts/8)─┐ > >> └─(09:44:39 on master)──> > > > > Thanks for all the details. It's great that your system is now fixed. Do > > you have an idea why libc6 2.34 ended up in /usr/lib/x86_64-linux-gnu? > > I do not see any explanation from the glibc side. Did you attempt a > > usrmerge migration that failed after moving some files, or do you think > > it's unrelated? > > > > I seriously did not have a clue why system was in this state. I had > installed system back in 2019 and just keep updating. Also it was not > just glibc, a whole bunch of packages were in this state and it took me a > while to fix the entire system. (Had to write script to automate entire > process). > > I don't remember me attempting to install usrmerge but not sure if it > came via some dependency and failed to install. Feels weird why system > was in such a state. Ok, I am therefore closing the bug as it is not a glibc issue. Please feel free to open a bug to another package if you find the culprit. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
--- End Message ---
