Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#1275 - Pacman Segfault with groups
Attached to Project:
Pacman
Opened by Jake Brownson (jbNet) - Friday, 20 August 2004, 04:40 GMT
Last edited by Judd Vinet (judd) - Friday, 20 August 2004, 16:40 GMT
Opened by Jake Brownson (jbNet) - Friday, 20 August 2004, 04:40 GMT
Last edited by Judd Vinet (judd) - Friday, 20 August 2004, 16:40 GMT
|
DetailsLooks like I've found a segfault in Pacman. I set up a fresh UML (user mode linux) system with just the basic packages and get it up on the network, then do a "pacman -S kde"...
:: group kde: arts gwenview kdeaccessibility kdeaddons kdeadmin kdeartwork kdebase kdebindings kdeedu kdegames kdegraphics kdelibs kdemultimedia kdenetwork kdepim kdesdk kdetoys kdeutils Install whole content? [Y/n] Targets: audiofile-0.2.6-1 alsa-lib-1.0.6-1 libjpeg-6b-3 qt-3.3.3-2 libmad-0.15.1b-1 libogg-1.1-1 libvorbis-1.0.1-1 pkgconfig-0.15.0-1 glib2-2.4.6-1 esd-0.2.34-1 arts-1.2.3-1 libgpg-error-0.7-1 libgcrypt-1.1.94-1 libxslt-1.1.8-1 pcre-4.5-1 lesstif-0.93.94-1 libart-lgpl-2.3.16-1 portmap-5beta-9 fam-2.6.10-3 openldap-2.2.13-3 libtiff-3.6.1-3 cups-1.1.20-3 kdelibs-3.2.3-1 gwenview-1.1.3-1 kdeaccessibility-3.2.3-1 cdparanoia-9.8-4 lame-3.96-1 flac-1.1.0-4 musicbrainz-2.1.1-1 trm-0.2.1-2 taglib-1.2-1 sdl-1.2.7-1 codecs-20040706-1 xine-lib-1rc5-3 kdemultimedia-3.2.3-1 kdeaddons-3.2.3-1 kdebase-3.2.3-1 kdeadmin-3.2.3-1 kdeartwork-3.2.3-1 kdebindings-3.2.3-1 kdeedu-3.2.3-1 kdegames-3.2.3-1 glib-1.2.10-4 gtk-1.2.10-4 libungif-4.1.0-2 imlib-1.9.14-4 glut-3.7-4 libieee1284-0.2.8-1 libusb-0.1.8-5 sane-1.0.14-5 libexif-0.6.9-1 libgphoto2-2.1.4-2 lcms-1.13-1 fribidi-0.10.4-1 gimp-print-4.2.7-1 ghostscript-7.07.1-5 kdegraphics-3.2.3-1 kdenetwork-3.2.3-1 kdepim-3.2.3-1 kdesdk-3.2.3-1 kdetoys-3.2.3-1 zip-2.3-2 rar-3.3.0-1 kdeutils-3.2.3-1 Proceed with upgrade? [Y/n] checking package integrity... done. loading package data... Segmentation fault Here's pacman -V: .--. Pacman v2.8.3 / _.-' .-. .-. .-. Copyright (C) 2002-2004 Judd Vinet <jvinet@zeroflux.org> \ '-. '-' '-' '-' '--' This program may be freely redistributed under the terms of the GNU General Public License I am able to reproduce this problem on another machine not running on UML, but normally This also happens when doing pacman -S gnome [snip] checking package integrity... done. loading package data... done. checking for file conflicts... done. installing pkgconfig... Segmentation fault Can anybody reproduce anything like this? Want any more information? I'll probably try and track it down myself too. When I don't use groups it seems to work just fine. Thanks, ~Jake B 
pacman.tar.bz2
|
This task depends upon
[snip]
reading /var/cache/pacman/pkg/cups-1.1.20-3.pkg.tar.gz... done
reading /var/cache/pacman/pkg/kdelibs-3.2.3-1.pkg.tar.gz... done
reading /var/cache/pacman/pkg/gwenview-1.1.3-1.pkg.tar.gz... Segmentation fault
This the 2nd 3rd 4th and 5th time:
reading /var/cache/pacman/pkg/libtiff-3.6.1-3.pkg.tar.gz... done
reading /var/cache/pacman/pkg/cups-1.1.20-3.pkg.tar.gz... done
reading /var/cache/pacman/pkg/kdelibs-3.2.3-1.pkg.tar.gz... Segmentation fault
With gnome:
1st time:
rep-gtk-0.18-1.pkg.tar.gz is already in the cache
vte-0.11.11-1.pkg.tar.gz is already in the cache
checking package integrity... Segmentation fault
2nd time:
gtk-engines-2.2.0-3.pkg.tar.gz is already in the cache
gmp-4.1.3-1.pkg.tar.gz is already in the cache
:: Retrieving packages from current...
Segmentation fault
I'm beginning to suspect libtar or something? I'm going to recompile those from abs and recompile pacman to staticaly link the new ones. doesn't seem to have any effect...
However, if I just list the packages in the group manually on the command line, it works great... Must be specific to groups... anyway that's all for tonight.
[snip]
done.
Executing post-install script...
var/lib/pacman/local/kdelibs-3.2.3-1/install: line 1: 178 Segmentation fault sbin/ldconfig -r .
installing gwenview... extracting files...
Updating database...done.
done.
[snip]
installing kdemultimedia... extracting files...
Updating database...done.
done.
installing kdeaddons... extracting files...
Segmentation fault
then I get the command prompt back
if I run it a second time it works... didn't see any segfaults this time. This seems to be a tricky one.
Could you tar up /var/lib/pacman when it's in such a state that a certain --sync call will definitely make it segfault? I've been trying to isolate this problem for a few weeks now and I can't reproduce it myself.
If you can get a db that reproduced the error, please attach it to this bug. Thanks!
reading /var/cache/pacman/pkg/kdemultimedia-3.2.3-1.pkg.tar.gz... done
reading /var/cache/pacman/pkg/kdeaddons-3.2.3-1.pkg.tar.gz... done
reading /var/cache/pacman/pkg/kdebase-3.2.3-1.pkg.tar.gz... Segmentation faul
(I did this right after I uploaded)
Also on pacman -Sv gnome it segfaults like this:
(I did this right after I tried kde)
reading /var/cache/pacman/pkg/gmp-4.1.3-1.pkg.tar.gz... done
reading /var/cache/pacman/pkg/librep-0.16.1-2.pkg.tar.gz... done
reading /var/cache/pacman/pkg/rep-gtk-0.18-1.pkg.tar.gz... done
reading /var/cache/pacman/pkg/vte-0.11.11-1.pkg.tar.gz... done
done.
checking for file conflicts... done.
installing pkgconfig... extracting files...
Updating database...done.
done.
installing glib2... Segmentation fault
I am doing this in a UML system created with Xentac's handy script.
A thought just occured to me, maybe it's memory... I'm using the defaults on uml, and it looks like that limits me to 28 Megs... I'm going to increase that to 256 Megs... Hah that's it! both kde and gnome work like a charm now. Maybe pacman should do some more checking on it's mallocs :). I could probably work on this if you wanted. This must be why it only seemed to happen on groups, because those operations take a bit more memory, and that's also why it was so random.
Could this be the same problem you were talking about?
Almost all mallocs go through a macro wrapper which checks the retcode from malloc() and complains loudly if it fails.
Thanks for helping me out with this. I'll play around with it some more (maybe from a UML) and see if I can reproduce it.
I'll leave this bug open. Let me know if you see the segfault again. Thanks.