FS#21668 - Pacman segfault when full update
Attached to Project:
Pacman
Opened by Jocelyn Boullier (Kazy) - Thursday, 11 November 2010, 14:44 GMT
Last edited by Dan McGee (toofishes) - Monday, 13 December 2010, 04:31 GMT
Opened by Jocelyn Boullier (Kazy) - Thursday, 11 November 2010, 14:44 GMT
Last edited by Dan McGee (toofishes) - Monday, 13 December 2010, 04:31 GMT
|
Details
When i do a pacman -Syu, i've got a Segfault (it seems to be
right after the sync step). I use pacman-3.4.1-1.
I don't know at all how you can reproduce it. I have attached the "pacman -Syu --debug" & "strace pacman -Syu" output. |
This task depends upon
Closed by Dan McGee (toofishes)
Monday, 13 December 2010, 04:31 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed what we can with the segfault, but the database problem does not look like we could be at fault.
Monday, 13 December 2010, 04:31 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed what we can with the segfault, but the database problem does not look like we could be at fault.
I have tried a pacman -S glibc, and it worked. I have glibc 2.12.1-4 now.
And I don't know if it can be usefull, but my ArchLinux ran into a virtual machine (virtualbox).
https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces
Here is my gdb trace, but only without debugging symbols:
Starting program: /usr/bin/pacman -Syu
[Thread debugging using libthread_db enabled]
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
:: Starting full system upgrade...
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff78d8d66 in strcmp () from /lib/libc.so.6
(gdb) bt
#0 0x00007ffff78d8d66 in strcmp () from /lib/libc.so.6
#1 0x00007ffff7bd4b7f in alpm_trans_prepare () from /usr/lib/libalpm.so.5
#2 0x000000000040a47d in ?? ()
#3 0x0000000000407137 in ?? ()
#4 0x00007ffff787dc4d in __libc_start_main () from /lib/libc.so.6
#5 0x00000000004041c9 in ?? ()
#6 0x00007fffffffea68 in ?? ()
#7 0x000000000000001c in ?? ()
#8 0x0000000000000002 in ?? ()
#9 0x00007fffffffecc9 in ?? ()
#10 0x00007fffffffecd9 in ?? ()
#11 0x0000000000000000 in ?? ()
(gdb) quit
http://blema.cz/temp/pacman.corrupted
Here you can find corresponding /var/lib/pacman:
http://blema.cz/temp/var.lib.pacman.tbz
dmcgee@galway /tmp/var/lib/pacman/sync/core/coreutils-8.7-1
$ cat desc
P1010250a.JPGP1010255a.JPGP1010260a.JPGP1010341a.JPGP1010344a.JPGP1010345a.JPGP1010348a.JPGP1010349a.JPGP1010365a.JPGP1010370a.JPGP1010372a.JPGP1010439a.JPGP1010442a.JPGP1010445a.JPGP1010447a.JPGP1010450a.JPGP1010453a.JPGP1010455a.JPGP1010461a.JPGP1010469a.JPGP1010476a.JPGP1010479a.JPGL��u/home/civ/kb-klicstare certifikatyČÍŽEK_VÍTĚZSLAV.p12L��u/h
That is not cool at all. I'm also not sure how this is related to the original report that seemed to point at extra/orc being busted. And what the heck was reported, is this some other ticket in our tracker?
$ ./src/pacman/pacman --dbpath /tmp/var/lib/pacman/ -Si kernel26
error: package 'kernel26' was not found
I can reproduce (using pacman-maint branch):
$ fakeroot ./src/pacman/pacman --dbpath /tmp/var/lib/pacman/ -Su
:: Starting full system upgrade...
:: Replace python-numpy with extra/python2-numpy? [Y/n] y
error: segmentation fault
Internal pacman error: Segmentation fault.
Please submit a full bug report with --debug if appropriate.
With GDB:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff603bd66 in strcmp () from /lib/libc.so.6
(gdb) bt full
#0 0x00007ffff603bd66 in strcmp () from /lib/libc.so.6
No symbol table info available.
#1 0x00007ffff79c9ec7 in check_arch (data=0x7fffffffde30) at trans.c:110
pkg = 0x722a50
pkgarch = 0x6852f0 "x86_64"
i = 0x85a510
invalid = <value optimized out>
arch = 0x616920 "x86_64"
#2 alpm_trans_prepare (data=0x7fffffffde30) at trans.c:148
trans = 0x65ace0
__func__ = "alpm_trans_prepare"
invalid = 0x0
Which is actually a lie if you add a printf; turns out pkgarch is null and we die, not surprising since we did 0 sanity checks on the values here. Adding a null check to pkgarch fixes the problem (we already checked if arch was null outside the loop). Patch going to the ML.
http://blema.cz/temp/var.lib.pacman.g-m.tbz
I deleted them, when trying to search for corrupted package.
An additional corrupted package is here core/linux-firmware.