[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1020559: marked as done (libc6: After upgrading libc6 expr is crashing with "stack smashing detected")

Your message dated Mon, 26 Sep 2022 08:57:46 +0200
with message-id <YzFNamTSh0rIqe+d@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 owner@bugs.debian.org
immediately.)


-- 
1020559: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020559
Debian Bug Tracking System
Contact owner@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:

Attachment: 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 <aurelien@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
aurelien@aurel32.net                 http://www.aurel32.net

--- End Message ---
Reply to: