FS#67670 - segmentation fault while doing pacman -Syu

Attached to Project: Pacman
Opened by Serge (SR-G) - Saturday, 22 August 2020, 09:00 GMT
Last edited by Allan McRae (Allan) - Tuesday, 09 February 2021, 04:28 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To No-one
Architecture x86_64
Severity High
Priority Normal
Reported Version 5.2.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Summary and Info:

Since today, i'm running pacman -Syu on one server and i get a "segmentation fault".
Not unable to solve this issues in any way ... :
- there is at this time no space issues (/tmp has space, /var/log also, same for /var/cache/ ...)
- replacing mirrors by other mirrors in etc/pacman.d/mirrorlist does not help
- removing the /var/lib/pacman/sync db files does not help

Stack :

pacman --debug -Syu
debug: pacman v5.2.2 - libalpm v12.0.2
debug: config: attempting to read file /etc/pacman.conf
debug: config: new section 'options'
debug: config: HoldPkg: pacman
debug: config: HoldPkg: glibc
debug: config: arch: x86_64
debug: config: SigLevel: Required
debug: config: SigLevel: DatabaseOptional
debug: config: LocalFileSigLevel: Optional
debug: config: new section 'core'
debug: config file /etc/pacman.conf, line 76: including /etc/pacman.d/mirrorlist
debug: config: new section 'extra'
debug: config file /etc/pacman.conf, line 79: including /etc/pacman.d/mirrorlist
debug: config: new section 'community'
debug: config file /etc/pacman.conf, line 85: including /etc/pacman.d/mirrorlist
debug: config: finished parsing /etc/pacman.conf
debug: setup_libalpm called
debug: option 'logfile' = /var/log/pacman.log
debug: option 'gpgdir' = /etc/pacman.d/gnupg/
debug: option 'hookdir' = /etc/pacman.d/hooks/
debug: option 'cachedir' = /var/cache/pacman/pkg/
debug: registering sync database 'core'
debug: database path for tree core set to /var/lib/pacman/sync/core.db
debug: "/var/lib/pacman/sync/core.db" is not readable: Aucun fichier ou dossier de ce type
debug: setting usage of 15 for core repository
debug: adding new server URL to database 'core': https://mirror.cyberbits.eu/archlinux/core/os/x86_64
debug: registering sync database 'extra'
debug: database path for tree extra set to /var/lib/pacman/sync/extra.db
debug: "/var/lib/pacman/sync/extra.db" is not readable: Aucun fichier ou dossier de ce type
debug: setting usage of 15 for extra repository
debug: adding new server URL to database 'extra': https://mirror.cyberbits.eu/archlinux/extra/os/x86_64
debug: registering sync database 'community'
debug: database path for tree community set to /var/lib/pacman/sync/community.db
debug: "/var/lib/pacman/sync/community.db" is not readable: Aucun fichier ou dossier de ce type
debug: setting usage of 15 for community repository
debug: adding new server URL to database 'community': https://mirror.cyberbits.eu/archlinux/community/os/x86_64
:: Synchronisation des bases de données de paquets…
debug: url: https://mirror.cyberbits.eu/archlinux/core/os/x86_64/core.db
debug: maxsize: 134217728
debug: opened tempfile for download: /var/lib/pacman/sync/core.db.part (wb)

error: segmentation fault
Please submit a full bug report with --debug if appropriate.

Content of /var/lib/pacman/sync :
-rw-r--r-- 1 root root 5,2M 2020-08-22 09:50 community.db
-rw-r--r-- 1 root root 132K 2020-08-21 21:13 core.db
-rw-r--r-- 1 root root 0 2020-08-22 10:48 core.db.part
-rw-r--r-- 1 root root 1,7M 2020-08-22 09:36 extra.db

I can write files in that folder without any issues.

root:sync/ # ll [10:57:24]
total 6,9M
-rw-r--r-- 1 root root 5,2M 2020-08-22 09:50 community.db
-rw-r--r-- 1 root root 132K 2020-08-21 21:13 core.db
-rw-r--r-- 1 root root 0 2020-08-22 10:48 core.db.part
-rw-r--r-- 1 root root 1,7M 2020-08-22 09:36 extra.db
-rw-r--r-- 1 root root 11 2020-08-22 10:57 test
root:sync/ # cat test [10:57:25]
write test



Steps to Reproduce:

Just run pacman -Syu

Seems NOT directly the same than FS#53904.
This task depends upon

Closed by  Allan McRae (Allan)
Tuesday, 09 February 2021, 04:28 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Appears to be an issue in a dependency.
Comment by Serge (SR-G) - Saturday, 22 August 2020, 09:10 GMT
I have a coredump generated ... :

oût 22 11:05:19 ns350873 systemd-coredump[2030596]: Process 2030593 (pacman) of user 0 dumped core.

Stack trace of thread 2030594:
#0 0x00007f02203e2615 raise (libc.so.6 + 0x3d615)
#1 0x000055e84c6aefc1 n/a (pacman + 0x10fc1)
#2 0x00007f02203e26a0 __restore_rt (libc.so.6 + 0x3d6a0)
#3 0x00007f021eca64f2 n/a (libnss_resolve.so.2 + 0x2b4f2)
#4 0x00007f021eca8042 n/a (libnss_resolve.so.2 + 0x2d042)
#5 0x00007f021ec92950 n/a (libnss_resolve.so.2 + 0x17950)
#6 0x00007f021eca7c41 n/a (libnss_resolve.so.2 + 0x2cc41)
#7 0x00007f021ec8a713 _nss_resolve_gethostbyname4_r (libnss_r>
#8 0x00007f022048e146 gaih_inet.constprop.0 (libc.so.6 + 0xe9>
#9 0x00007f022048efc9 getaddrinfo (libc.so.6 + 0xe9fc9)
#10 0x00007f022029a738 n/a (libcurl.so.4 + 0x13738)
#11 0x00007f02202932d3 n/a (libcurl.so.4 + 0xc2d3)
#12 0x00007f022029d9bb n/a (libcurl.so.4 + 0x169bb)
#13 0x00007f021fa1f3e9 start_thread (libpthread.so.0 + 0x93e9)
#14 0x00007f02204a5293 __clone (libc.so.6 + 0x100293)

Stack trace of thread 2030593:
#0 0x00007f022049a46f __poll (libc.so.6 + 0xf546f)
#1 0x00007f02202cf4bd n/a (libcurl.so.4 + 0x484bd)
#2 0x00007f02202c44ad n/a (libcurl.so.4 + 0x3d4ad)
#3 0x00007f02202c4636 curl_multi_poll (libcurl.so.4 + 0x3d636)
#4 0x00007f022029e701 curl_easy_perform (libcurl.so.4 + 0x177>
#5 0x00007f0220646aae n/a (libalpm.so.12 + 0x16aae)
#6 0x00007f0220640434 alpm_db_update (libalpm.so.12 + 0x10434)
#7 0x000055e84c6b516d n/a (pacman + 0x1716d)
#8 0x000055e84c6b07b1 n/a (pacman + 0x127b1)
#9 0x000055e84c6a5238 n/a (pacman + 0x7238)
#10 0x00007f02203cd152 __libc_start_main (libc.so.6 + 0x28152)
#11 0x000055e84c6a644e n/a (pacman + 0x844e)
Comment by Allan McRae (Allan) - Saturday, 22 August 2020, 09:28 GMT
My guess is this is not a pacman issue as such, rather something you updated yesterday. What packages were involved in the previous update?
Comment by Serge (SR-G) - Saturday, 22 August 2020, 09:35 GMT
I would say it's these packages :

2020-08-22T00:17:03+0200] [ALPM] transaction started
[2020-08-22T00:17:03+0200] [ALPM] upgraded linux-api-headers (5.6.11-1 -> 5.7-1)
[2020-08-22T00:17:04+0200] [ALPM] warning: /etc/locale.gen installed as /etc/locale.gen.pacnew
[2020-08-22T00:17:04+0200] [ALPM] upgraded glibc (2.31-5 -> 2.32-2)
[2020-08-22T00:17:09+0200] [ALPM] upgraded gcc-libs (10.1.0-2 -> 10.2.0-1)
[2020-08-22T00:17:09+0200] [ALPM] upgraded systemd-libs (246.2-1 -> 246.2-2)
[2020-08-22T00:17:09+0200] [ALPM] upgraded libp11-kit (0.23.20-5 -> 0.23.21-1)
[2020-08-22T00:17:09+0200] [ALPM] upgraded p11-kit (0.23.20-5 -> 0.23.21-1)
[2020-08-22T00:17:09+0200] [ALPM] upgraded libutil-linux (2.36-1 -> 2.36-2)
[2020-08-22T00:17:09+0200] [ALPM] upgraded curl (7.71.1-1 -> 7.72.0-2)
[2020-08-22T00:17:09+0200] [ALPM] upgraded binutils (2.34-5 -> 2.35-1)
[2020-08-22T00:17:12+0200] [ALPM] upgraded gcc (10.1.0-2 -> 10.2.0-1)
[2020-08-22T00:17:12+0200] [ALPM] upgraded glib2 (2.64.4-1 -> 2.64.5-1)
[2020-08-22T00:17:12+0200] [ALPM] installed libxcrypt (4.4.16-3)
[2020-08-22T00:17:12+0200] [ALPM] upgraded haproxy (2.2.2-1 -> 2.2.2-2)
[2020-08-22T00:17:12+0200] [ALPM] upgraded libtool (2.4.6+42+gb88cebd5-13 -> 2.4.6+42+gb88cebd5-14)
[2020-08-22T00:17:19+0200] [ALPM] upgraded linux-firmware (20200721.2b823fc-1 -> 20200817.7a30af1-1)
[2020-08-22T00:17:23+0200] [ALPM] upgraded util-linux (2.36-1 -> 2.36-2)
[2020-08-22T00:17:26+0200] [ALPM] upgraded systemd (246.2-1 -> 246.2-2)
[2020-08-22T00:17:32+0200] [ALPM] upgraded linux-lts (5.4.58-1 -> 5.4.59-1)
[2020-08-22T00:17:32+0200] [ALPM] upgraded man-pages (5.07-1 -> 5.07-2)
[2020-08-22T00:17:32+0200] [ALPM] upgraded systemd-sysvcompat (246.2-1 -> 246.2-2)

(i tried previous version of curl, but same behavior)
Comment by Allan McRae (Allan) - Thursday, 03 September 2020, 01:13 GMT
Did the recent updates to glibc fix this?
Comment by Serge (SR-G) - Thursday, 03 September 2020, 06:31 GMT
I think so ... the other day, i had to manually downgrad all recently upgraded packages (hopefuly still available in /var/cache/pacman/pkg/) to recover the situation, and now after a full system upgrade it seems also OK...

Loading...