Red Hat Bugzilla – Bug 107320
RPM segmentation fault when installing or erasing packages
Last modified: 2007-04-18 12:58:30 EDT
Description of problem:
rpm give segmentation fault when installing or erasing packages
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. rpm -i *anypackage*.rpm
2. rpm -u *anypackage*.rpm
3. rpm -e *anypackage*.rpm
Gives error: "Segmentation fault" and dies.
Istall, update or erase the package as requested.
Everything else works fine. Rpm checks the packages and dependencies and
reports in case of dependencies correctly. Queries and (database) rebuilds also
work fine. When testing, even with --nodeps and/or --force still everythings
fine. It is when actually trying to install, upgrade or remove a package when
rpm just dies. It does not hang, though the symptoms are the same -
/var/lib/rpm shows the __db.00? files.
Upgrading to rpm-4.1.1 from ftp.rpm.org recommended.
Does "rpm -qa" segfault?
No. It shows installed packages as it should.
OK. Does problem track with specfic package or generally?
(add -vv for copious detail).
You might try LD_ASSUME_KERNEL=2.4.19 rpm ... prefix, that
You might also try adding --nosignature and/or --nodigest.
Any of that help?
If it's any help, I get the exact same error with a different RPM, and it
started right after I went to glibc2.3 (2.3.2-98, from a bunch of RPMs) on
RPM4.0.4-7x (installed through rpm) segfaults right after install, erase or
RPM 4.1 (from .i386.tar.gz) segfaults in exactly the same spot.
Doesn't matter which rpm, everything fails. -qa gives a good list, --test also
gives no errors, dependencies work more or less ok, but (imho) as soon as it
needs to write something to the database it just segfaults.
I tried recompiling rpm from scratch, but I'm missing some parts (complains
about db3 in particular, probably needs db3-devel) which I do not have
installed according to 'rpm -qa', but cannot install either cause rpm segfaults.
Using strace, I see it die right after doing something with ld-linux.so.2.
(I tried to manually override it back to the older version, totally hosed my
system, hit myself on the head - should've known glibc is connected to
Tried rpm --rebuilddb, completes without errors, but doesn't help. In other
words, *exactly* the same problem the bugstarter is having.
Bug# 86197 lists exactly my behaviour regarding segfault, any chance this bug
is the same? Check if 'nscd -d' also segfaults, if so, let's merge the two bugs.
If this helps anyone, I am having the same problem on RH 8 with rpm-4.1-1.06
after upgrading glibc to 2.3.2-11.9 using the glibc RPMs. rpm -vv gives me the
following lines when erasing a package:
D: erase: joe-2.9.7-1 has 12 files, test = 0
D: opening db index /var/lib/rpm/Name create mode=0x42
D: read h# 502 Header sanity check: OK
rpm -vv gives me the following lines when installing a package:
D: ========== +++ j2re-1.4.2_02-fcs
D: Expected size: 13778791 = lead(96)+sigs(100)+pad(4)+data(13778591)
D: Actual size: 13778759
D: install: j2re-1.4.2_02-fcs has 669 files, test = 0
I don't know how to safely downgrade to the older version of glibc without rpm,
so I'm stuck here...
We have succesfully worked around this problem!
Actually, it seems, that the party to blame here isn't rpm, but glibc as J. F.
van Baarlen mentioned. I too had the problem occuring right after installing
upgrade-rpms (from funet.fi - mirror of redhat.com). I think our glibc was
2.2.93-5 and we tried to upgrade to the formentioned 2.2.98-X.
What we did then? We restored the original (non-buggy) state of the operating
systems from backups. After that we still had some problems with RPM-based
installation depending on glibc. This could be worked around stating the
environment variable LD_ASSUME_KERNEL=2.2.5. However this did not solve all our
issues, just enough to get the rpm to work (or, at least to install and
upgrade). Then we upgraded (since we got rpm to work) the whole bunch of glibcs
to version 2.3.2-4.80.6. Since the processor is P4 or greater, we took extra
care that the glibc packages that were available as i686.rpm were installed
instead of i386.rpm. Also we took care to upgrade the glibcs so that every
package and file would really be replaced with the --replacepkgs --replacefiles
Now everything works fine - if you don't count the one little thing; operating
system now "speaks" finnish every now and then even though every step of way
have chosen us-english as our operating system language...
Causes Segmentation fault under Fedora Core 1, rpm 4.2.1-0.30 and glibc-2.3.2-101 while reading DSA signatures. Doesn't install, update or rebuild database
This appears to be the same problem that is in bug 111400 (which was
closed as NEEDINFO for some reason.) I installed the same versions of
RPM and LIBC as the guy in 111400 and I'm getting the same problem.
So, the bug seems to be easily reproducible.
One report per bug, please, me too's just confuse everything.
tommi: do you have fix yet?
Ah, yes, happy customer, WORKSFORME.
Yes, a happy customer - thanks to you all! I hope someone comes up
with a better solutions for this, since ours solely depends on having
a working backup set - which is not obviously allways the case.
Looking back at the problem I should warn everyone though... In the
previous RH versions (7.0 and earlier if I recall correctly) one could
allways install .i386 rpm-package regardless of the "required" or
"correct" rpm-package (.i386, .i586 or .i686 depending on your
platform, of course). This is not the case anymore (as one one knows
if one does the good-old RTFM... ;-). So in future be careful with the
packages - always be sure that it really does suit your environment.
Thanks to you all, and have a good '04!