Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 55671 - rpm results in Segmentation fault and core dump
rpm results in Segmentation fault and core dump
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Depends On:
  Show dependency treegraph
Reported: 2001-11-04 09:53 EST by Matthew A. Cannon
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-12-03 15:55:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
rpmdb tar bal (1.50 MB, application/octet-stream)
2001-11-04 09:56 EST, Matthew A. Cannon
no flags Details
Error text from tar file creation and db_verify (2.27 KB, text/plain)
2001-11-04 10:08 EST, Matthew A. Cannon
no flags Details
Installed Package List for 55671 (9.78 KB, text/plain)
2001-11-26 13:30 EST, Matthew A. Cannon
no flags Details

  None (edit)
Description Matthew A. Cannon 2001-11-04 09:53:36 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.17-14 i686)

Description of problem:
Using rpm to query installed packages (rpm -qa) results in a segmentation
fault and core dump.  I suspect there is some kind of data corruption
within the rpm db as rpm --rebuilddb produces a segmentation fault and core
dump as well.  I have also run a db_verify against the databases in
/var/lib/rpm and it does report back errors on certain databases.  I
understand there is a workaround t38454, however it appears that the
program requires the bad records to be specified in an array and I am
uncertain how to do this correctly and  am not even sure if using this
workaround would be appropriate.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.rpm -qa

Actual Results:  texinfo-4.0-15
Segmentation fault (core dumped)	

Expected Results:  Full listing of installed packages	

Additional info:

This problem appears similar to ones previously reported.  I have created a
tar ball of my rpm database and can send it if needed.  I can also send the
output from the db_verify command that was executed against the rpm


Matt Cannon
Comment 1 Matthew A. Cannon 2001-11-04 09:56:50 EST
Created attachment 36342 [details]
rpmdb tar bal
Comment 2 Matthew A. Cannon 2001-11-04 10:08:38 EST
Created attachment 36343 [details]
Error text from tar file creation and db_verify
Comment 3 Jeff Johnson 2001-11-04 10:12:55 EST
Do a --rebuilddb with rpm-4.0.3-1.03 from (amongst other places)

Use rpm2cpio to install if you have to. Assuming all 6 rpm
packages are in /var/tmp, the procedure (as root) is
    mkdir /var/tmp/xxx
    cd /var/tmp/xxx
    for i in /var/tmp/{rpm,popt}-*
        rpm2cpio $i | cpio -dim
    find . -type d -exec chmod 755 {} \;
    tar cf - . | (cd /; tar xvf -)

Then an rpm --rebuilddb should fix your problem.
Comment 4 Matthew A. Cannon 2001-11-23 10:12:47 EST
Please cc mcannon@mindspring.com on any ticket correspondence.  I'm having
trouble with my mailserver on cannon-consultants.com (thanks!).

Follow instructions provided.
1. Installed 6 rpm-4.0.3-1.03 packages (including popt) using rpm2cpio
2. Executed rpm --rebuilddb and received the following error message:

   error: rpmdb: damaged header instance #36 retrieved, skipping
   Segmentation fauld (core dumped)

Two additional files were created in /var/lib/rpm:


One additional directory with 11 files created (looks like a working directory):


Executing rpm -qa yields the following error:

   error: cannot open Packages index using db1 - No such file or directory (2)

Let me know if you want the core file or a tarball containing the rebuilddb files.


Matt Cannon
Comment 5 Jeff Johnson 2001-11-23 10:27:36 EST
OK, give me a pointer (i.e. URL, attachments won't work as rpmdb files
are too big) to a tarball of your database
	cd /var/lib
	tar czvf /tmp/rpmdb-55671.tar.gz rpm
and I'll see what I can do.
Comment 6 Matthew A. Cannon 2001-11-23 11:11:25 EST
I have included a URL to a tar file containing my rpm database.  It appears that
the only differences between the new tar file and the one originally attached to
this ticket are the presence of the core file and the __db.00[1-2] files in the
new tar file (both of which were created after running the rebuilddb option
after 4.0.3 was installed).

  The URL is http://cannon-consultants.com/rpmdb-55671.tar.gz

I sincerely appreciate your assistance.


Matt Cannon
Comment 7 Jeff Johnson 2001-11-23 16:06:45 EST
Hmmm, your database is pretty smashed, dunno if I can save much.

You can see what I'm looking at if you do (you need the db3-utils package)
	db_verify /var/lib/rpm/Packages

The segfault is on header instance #56. If I carefully avoid that, I see
nothing but bad headers. I can try a few more things, but it's looking
bad. I'll help you get through the reconstruction however ...

Any idea how you got to this state? Any hints/clues are appreciated, so
that I can try to prevent this from happening in the future.

Comment 8 Matthew A. Cannon 2001-11-23 22:13:21 EST
I believe I tried the early steps (db_verify and then db_dump Packages.old |
db_load Packages) from ticket 38454 before I created this ticket, but stopped
short before executing the t38454 C program.  The problem I was originally
experiencing (gripes about an assertion being violated in header.c after
installing 4.0.2-7x rpm) was quite similar to the one described in 38454.  After
looking at the source of the t38454 program, it looked like it had hard coded
records that it was trying to delete and that's when I stopped and created this
ticket (reference initial comment on 55671). Where I think I might have really
goofed (not sure if I did this or why if I did) is when I executed a rpm
--rebuilddb after the db_verify, db_dump and db_load.  This is when I started to
notice the Segmentation faults and created 55671.  I didn't leave myself a very
good crumb trail (keeping an original Packages - pre dump/re-load) and I should
have been more patient.
After reading the paragraph I just wrote I realized this information might have
been helpful in the original comment.  My guess is this whole situation is 5%
problem with rpm, 95% problem with end-user's solution methodology.  At any
rate, thanks for any assistance and if there's something tedious I can do to
help myself out here, let me know.  I don't know if it helps, but my installed
package list is on the RedHat Network.


Matt Cannon
Comment 9 Jeff Johnson 2001-11-26 08:15:17 EST
OK, there are 3 basic ways to recreate an rpm database.

1) Easiest is to reinstall. If you want to be clever, you can do
an install without making new file systems on your existing
partitions, thereby preserving all your existing files.

2) Tar up a copy of /var/lib/rpm from the most similar machine,
and then use rpm -Va to detect packages in the database
that don't match the files on disk (those packages can then
be reinstalled). This procedure converges fairly fast, does
have the draw back of losing certain information like
install times that is added to package headers when they are

3) Using the rpmdb-redhat (or equivalent) as a reference, go
to all the usual places (i.e. /bin, /sbin, /usr/bin, etc ...) and
repeatedly run
	rpm -qf --redhatprovides some_file_here
to discover the package that has the file, and then reinstalling
that package. If you want to preserve exactly what is on
your disk, you can install just the database entries with
	--justdb --noscripts --notriggers --nodeps
options to the usual install.

What's your pleasure?

Comment 10 Matthew A. Cannon 2001-11-26 13:30:04 EST
Created attachment 38644 [details]
Installed Package List for 55671
Comment 11 Matthew A. Cannon 2001-11-26 13:32:18 EST

I think I'll go for what's behind door #3.  I have an up-to-date package list 
from my system profile on RedHat Network (see attached list).  For the packages 
that aren't on the original distribution for 7.0, I assume I can use a remote 
location parameter for the updated or new version of the rpm files.  

A couple of questions:  How can I start with a clean slate with regard to the 
rpm database(s)?  Will installing the packages with the -- justdb --noscripts, -
-notriggers --nodeps establish the necessary db entries for future dependency 
checks for package installs/removes as well as file location information for 
package removal?


Matt Cannon
Comment 12 Jeff Johnson 2001-12-03 15:55:35 EST
Sorry for the delay ...

	mv /var/lib/rpm /var/lib/rpm-SAVE
	mkdir -p /var/lib/rpm
	rpm --initdb
is a "clean slate".

Yes, --justdb adds the metadata to the database, but does
not unpack payloads onto the file system.
Comment 13 Jeff Johnson 2001-12-09 13:12:43 EST
This problem looks to be on the way to solution. If I'm wrong,
reopen the bug.

Note You need to log in before you can comment on or make changes to this bug.