Crashes pacman on full system upgrade from existing core/extra/multilib install #218

Closed
opened 2023-11-05 09:59:14 +01:00 by kode54 · 7 comments

Here’s a pacman debug log:

https://f.losno.co/pacman.log

Here’s a pacman debug log: https://f.losno.co/pacman.log
Owner

Can you try getting the coredump via coredumpctl?

Can you try getting the coredump via `coredumpctl`?
Author

I had to:

sudo -i
ulimit -c unlimited

Because for some reason, root had ulimit -c set to 0.

Here's a backtrace from that:

#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=11, no_tid=no_tid@entry=0)
    at pthread_kill.c:44
#1  0x00007f5b1f1ac8a3 in __pthread_kill_internal (signo=11, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007f5b1f15c668 in __GI_raise (sig=sig@entry=11) at ../sysdeps/posix/raise.c:26
#3  0x00005612253f74dc in segv_handler (signum=11) at ../src/pacman/sighandler.c:113
#4  <signal handler called>
#5  __strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:287
#6  0x00007f5b1f3f1d73 in _alpm_sync_prepare (data=0x7ffd7205da10, handle=0x5612264d9020)
    at ../lib/libalpm/sync.c:472
#7  alpm_trans_prepare (handle=0x5612264d9020, data=data@entry=0x7ffd7205da10) at ../lib/libalpm/trans.c:141
#8  0x00005612253fedc7 in sync_prepare_execute () at ../src/pacman/sync.c:758
#9  0x00005612253ed8d0 in sync_trans (targets=<optimized out>) at ../src/pacman/sync.c:728
#10 pacman_sync (targets=<optimized out>) at ../src/pacman/sync.c:958
#11 main (argc=<optimized out>, argv=<optimized out>) at ../src/pacman/pacman.c:1258

Maybe I need to dump the filenames of the installed packages, somehow.

I had to: ``` sudo -i ulimit -c unlimited ``` Because for some reason, root had `ulimit -c` set to `0`. Here's a backtrace from that: ``` #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=11, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007f5b1f1ac8a3 in __pthread_kill_internal (signo=11, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007f5b1f15c668 in __GI_raise (sig=sig@entry=11) at ../sysdeps/posix/raise.c:26 #3 0x00005612253f74dc in segv_handler (signum=11) at ../src/pacman/sighandler.c:113 #4 <signal handler called> #5 __strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:287 #6 0x00007f5b1f3f1d73 in _alpm_sync_prepare (data=0x7ffd7205da10, handle=0x5612264d9020) at ../lib/libalpm/sync.c:472 #7 alpm_trans_prepare (handle=0x5612264d9020, data=data@entry=0x7ffd7205da10) at ../lib/libalpm/trans.c:141 #8 0x00005612253fedc7 in sync_prepare_execute () at ../src/pacman/sync.c:758 #9 0x00005612253ed8d0 in sync_trans (targets=<optimized out>) at ../src/pacman/sync.c:728 #10 pacman_sync (targets=<optimized out>) at ../src/pacman/sync.c:958 #11 main (argc=<optimized out>, argv=<optimized out>) at ../src/pacman/pacman.c:1258 ``` Maybe I need to dump the filenames of the installed packages, somehow.
Owner

strcmp in _alpm_sync_prepare seems to segfault. As far as I know that only happens if one of its args is not initialized.

0108e2c64e/lib/libalpm/sync.c (L472)

Maybe gdb can be used to dump the var content?

`strcmp` in `_alpm_sync_prepare` seems to segfault. As far as I know that only happens if one of its args is not initialized. https://gitlab.archlinux.org/pacman/pacman/-/blob/0108e2c64ebb46a9f44e6e211f6ebe25e54f91ac/lib/libalpm/sync.c#L472 Maybe gdb can be used to dump the var content?
Author

pkg2->filename is NULL.

*pkg2 is:

$5 = {name_hash = 5737442551468256197, filename = 0x0, base = 0x0, name = 0x5612278331f0 "libaccounts-qt",
  version = 0x5612278331d0 "1.16-3.1", desc = 0x0, url = 0x0, packager = 0x0, md5sum = 0x0, sha256sum = 0x0,
  base64_sig = 0x0, arch = 0x0, builddate = 0, installdate = 0, size = 0, isize = 0, download_size = 0,
  handle = 0x5612264d9020, licenses = 0x0, replaces = 0x0, groups = 0x0, backup = 0x0, depends = 0x0,
  optdepends = 0x0, checkdepends = 0x0, makedepends = 0x0, conflicts = 0x0, provides = 0x0, removes = 0x0,
  oldpkg = 0x0, ops = 0x7f5b1f406060 <sync_pkg_ops>, files = {count = 0, files = 0x0}, origin_data = {
    db = 0x5612264f37b0, file = 0x5612264f37b0 " \220M&\022V"}, origin = ALPM_PKG_FROM_SYNCDB,
  reason = ALPM_PKG_REASON_EXPLICIT, scriptlet = 0, infolevel = 0, validation = 0}

Attempting to sync it with the v3 repo enabled results in:

> yay -S libaccounts-qt
Sync Dependency (1): libaccounts-qt-1.16-3.1
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (package filename is not valid)
 -> error installing repo packages
pkg2->filename is NULL. *pkg2 is: ``` $5 = {name_hash = 5737442551468256197, filename = 0x0, base = 0x0, name = 0x5612278331f0 "libaccounts-qt", version = 0x5612278331d0 "1.16-3.1", desc = 0x0, url = 0x0, packager = 0x0, md5sum = 0x0, sha256sum = 0x0, base64_sig = 0x0, arch = 0x0, builddate = 0, installdate = 0, size = 0, isize = 0, download_size = 0, handle = 0x5612264d9020, licenses = 0x0, replaces = 0x0, groups = 0x0, backup = 0x0, depends = 0x0, optdepends = 0x0, checkdepends = 0x0, makedepends = 0x0, conflicts = 0x0, provides = 0x0, removes = 0x0, oldpkg = 0x0, ops = 0x7f5b1f406060 <sync_pkg_ops>, files = {count = 0, files = 0x0}, origin_data = { db = 0x5612264f37b0, file = 0x5612264f37b0 " \220M&\022V"}, origin = ALPM_PKG_FROM_SYNCDB, reason = ALPM_PKG_REASON_EXPLICIT, scriptlet = 0, infolevel = 0, validation = 0} ``` Attempting to sync it with the v3 repo enabled results in: ``` > yay -S libaccounts-qt Sync Dependency (1): libaccounts-qt-1.16-3.1 resolving dependencies... looking for conflicting packages... error: failed to prepare transaction (package filename is not valid) -> error installing repo packages ```
Owner

I removed libaccounts-qt-1.16-3.1. Should be rebuild within the next cycle. Can you try syncing after 3.1 is gone from the repo? (should be momentarily, as soon as the mirrors sync up)

I removed `libaccounts-qt-1.16-3.1`. Should be rebuild within the next cycle. Can you try syncing after 3.1 is gone from the repo? (should be momentarily, as soon as the mirrors sync up)

I had the same issue earlier today and this appears to have fixed it. Thanks!

I had the same issue earlier today and this appears to have fixed it. Thanks!
Author

Yeah, verified working.

Yeah, verified working.
anonfunc added the
bug
label 2023-11-06 11:08:28 +01:00
Sign in to join this conversation.
No description provided.