#953412 apt: segfault at 0 ip 00007f024bc54e6f sp 00007ffcc6b28d40 error 4 in libapt-pkg.so.5.0.2

Package:
apt
Source:
apt
Description:
commandline package manager
Submitter:
Félix Sipma
Date:
2021-10-31 05:00:03 UTC
Severity:
important
Tags:
#953412#5
Date:
2020-03-09 09:10:29 UTC
From:
To:
Running "apt upgrade" I got:

    Segmentation fault (core dumped)

/var/log/messages reports:

    Mar  9 10:03:48 laptop kernel: [ 3262.779582] apt[44617]: segfault at 0 ip 00007f024bc54e6f sp 00007ffcc6b28d40 error 4 in libapt-pkg.so.5.0.2[7f024bbe4000+148000]
    Mar  9 10:03:48 laptop kernel: [ 3262.779588] Code: 08 01 48 8d 35 1c b6 0d 00 4c 89 fa 48 8b 38 e8 a7 04 f9 ff 41 89 c4 84 c0 74 50 45 84 ed 74 21 48 8b 05 7c 7d 12 00 48 8b 38 <48> 8b 07 ff 10 41 89 c4 84 c0 0f 84 e3 00 00 00 48 8b 43 08 c6 00

Attached is the error output of "strace apt upgrade".

Note that the apt script ran by reportbug also failed, feel free to ask
for configuration files or other information if needed...

#953412#10
Date:
2020-03-09 09:26:49 UTC
From:
To:
Control: tag -1 moreinfo

What do you think an strace is going to tell us? Please Install gdb
and debug symbols for apt, libstdc++6, libc6, and produce
a backtrace. So libapt-pkg5.0-dbgsym, libstdc++6-dbgsym,
libc6-dbgsym at a minimum.

You might want to install systemd-coredump so that cores are
always dumped and stored and you can then analyze them with
coredumpctl gdb and get a backtrace there to send in bug report.


You probably want to configure gdb to log to a file and get
a full backtrace, then attach that file, e.g.

$ gdb --args apt upgrade
set logging overwrite on
set logging file /tmp/apt-crash.log
set logging on
set pagination 0
run
backtrace full
quit

$ ... attach /tmp/apt-crash.log to bug report ...


The same thing without the run if you used coredumpctl gdb, because,
um, you are analysing a prior crash rather than making it crash again :)

#953412#17
Date:
2020-03-09 09:49:04 UTC
From:
To:
Note that "apt whatever" also crashes, so I can't install anything.

I manually (using dpkg -i) installed aptitude in the meantime, ran
"aptitude upgrade" and it seems that apt is working again.

By chance, I already had systemd-coredump and gdb installed (but no
debug symbols), and "sudo coredumpctl gdb" reports something:

            PID: 63290 (apt-config)
            UID: 0 (root)
            GID: 0 (root)
         Signal: 11 (SEGV)
      Timestamp: Mon 2020-03-09 10:33:38 CET (9min ago)
   Command Line: apt-config shell ignore_regexp AptListbugs::IgnoreRegexp
     Executable: /usr/bin/apt-config
  Control Group: /user.slice/user-1000.slice/session-2.scope
           Unit: session-2.scope
          Slice: user-1000.slice
        Session: 2
      Owner UID: 1000 (gueux)
        Boot ID: 0215de477f574da5a7db213494365237
     Machine ID: bd1078e9de2113789ff1dde150518661
       Hostname: capeo
        Storage: /var/lib/systemd/coredump/core.apt-config.0.0215de477f574da5a7db213494365237.63290.1583746418000000000000.lz4
        Message: Process 63290 (apt-config) of user 0 dumped core.

                 Stack trace of thread 63290:
                 #0  0x00007f3605ab2000 n/a (libapt-private.so.0.0 + 0x69000)
                 #1  0x000056034fac30ac n/a (apt-config + 0x50ac)


So, maybe that can still help? If not, sorry. I'll try to follow your
suggestions and do a better bug report next time.

#953412#22
Date:
2020-03-19 23:12:13 UTC
From:
To:
Hello,
I tried to locate the source line of the address shown
in the /var/log/messages output.
But that failed but I found in the strace output that
it loads for some reason two libapt-pkg.so files ...

    ...
    openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libapt-pkg.so.6.0", O_RDONLY|O_CLOEXEC) = 3
    ...
    openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libapt-pkg.so.5.0", O_RDONLY|O_CLOEXEC) = 3
    ...

Just in case if that helps.

Kind regards,
Bernhard

#953412#27
Date:
2021-10-31 04:56:12 UTC
From:
To:
8465757