Red Hat Bugzilla – Bug 97589
segfault when dependencies are met
Last modified: 2007-04-18 12:54:53 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Description of problem:
When I run rpm to install/upgrade/remove a component, and that component's
dependency needs are not met, rpm will work fine and tell me the versions I
need. Once I resolve all these dependency issues, and pass all
applicable .rpm's on the command line, it segfaults. I also get a segfault when
trying to run a query or rebuild the database.
I was prompted to file a bug here when I read this page:
I have followed the directions: I backed up /var/lib/rpm, then
deleted /var/lib/rpm/__db*, then tried to rebuild the database, but it still
gave a segfault. I still have my rpmdb.tar.gz backup, as suggested on that page.
My rpm version is 4.1-1.06 (`rpm --version` shows 4.1, but if I try to upgrade
just rpm itself, rpm-python, -build, and -devel show version 4.1-1.06).
My kernel version is 2.4.7-10.
I don't know my glibc version.
The computer was originally RedHat7x, then was upgraded long ago to RedHat8, by
a professional. I have upgraded several packages since then, probably to
RedHat9-compatible versions; this may have caused the problem, I dunno.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Easiest way to reproduce: `rpm --rebuilddb`
Also: try to install/upgrade/remove and component whose dependency needs have
been met (see Description section).
Sanity check: Are you using LDAP passwords? If so than
you need to insure that nscd is running (won't hurt no matter what)
bash# service nscd start
openldap is installed, but I don't know if we are using LDAP passwords. The
main component we have that has a dependency on LDAP is sendmail, but I checked
out sendmail's configuration file and the only line that refers to LDAP is
commented out. If it takes a special effort to switch to using LDAP passwords,
then chances are we aren't. Is there a way to find out?
Running `/sbin/service nscd start` failed the first time I ran it. Running it
again did't say whether it failed or succeeded. Stopping it failed every time.
Trying again to start it still didn't say whether it failed or succeeded.
Running `/sbin/service nscd status` says "nscd dead but pid file exists".
After a reboot, nscd status is "stopped", starting nscd says "OK", but then
nscd status becomes "dead but pid file exists", and rpm is still segfaulting.
After that, nscd start still doesn't say whether it fails or succeeds, and nscd
stop still fails.
Can you provide a pointer (i.e. URL, attachments won't work)
to the tarbball of your database?
Sorry for the delayed response. You can get the tarball at
Hmmm, nscd failing to start is not a good sign.
I don't see anything wrong with your database, have
done --rebuilddb just in case.
Your rpm/Packages is at ftp://people.redhat.com/jbj/rpmdb-97589-FIX.tar.gz.
Download and install by doing
mv rpm/Packages rpm/Packages-ORIG
tar xzvf rpmdb-97589-FIX.tar.gz
rpm --rebuilddb -vv
Reopen this bug if the above doesn't fix.
No luck. Running `rpm --rebuilddb -vv` still segfaults. Also tried rebooting
and running it again; still segfaulted.
I did some test runs trying to install different things with the updated
database. It seems to be letting some packages through easier, and segfaults in
some cases where it used to say I had dependencies to resolve. However, I can
still get it to complain about package dependencies and not segfault (although
nothing gets installed, of course).
Does the database show any rpm/glibc/kernel incompatibility? i.e. could it be
an NPTL transition issue? That still seems to be the most likely case to me,
since we started with a previous installation of RedHat, and upgraded several
packages to their RedHat 9 versions.
I can't guess at incompatibilities. rpm is known to "work"
(i.e. not segfault) with released versions of glibc/kernel. Mixing
and matching versions of glibc/kernel/rpm is not advised because of NPTL.
Or install rpm-4.1.1 from
which doesn't use posix mutexes (i.e. no NPTL).