Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 7573 - rpm dumps core when RPMTAG_FILESTATES is missing
Summary: rpm dumps core when RPMTAG_FILESTATES is missing
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: rpm
Version: 1.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-12-03 23:52 UTC by sring
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-12-15 17:44:12 UTC


Attachments (Terms of Use)

Description sring 1999-12-03 23:52:07 UTC
I have been using rpm for almost 2 years now and that's the last time I did
a full system install, using rpm-2.4.something, I think. From then on, I
upgraded my system regularly, upgrading rpm itself several times on the
way. Some rpm versions had to rebuild the database in order to convert it
to a newer format, IIRC version 2.5.x and 2.9x. Having done these, I have
never had problems.

The problem is, however, that erasing a package from the old days now
sometimes gives me a core dump, and I've found out that some packages in
the database are missing the RPMTAG_FILESTATES tag, and that rpm seems to
assume that they exist. Maybe they were forgot when rebuilding and
upgrading the database. I have used the following quick hack to get rid of
the problem of not being able to upgrade these old packages:

--- rpm-3.0.4/lib/transaction.c.fix     Fri Nov 26 21:51:50 1999
+++ rpm-3.0.4/lib/transaction.c Fri Dec  3 12:25:32 1999
@@ -982,7 +982,7 @@
            }
            if (XFA_SKIPPING(fi->actions[i]))
                break;
-           if (fi->fstates[i] != RPMFILE_STATE_NORMAL)
+           if (fi->fstates && fi->fstates[i] != RPMFILE_STATE_NORMAL)
                break;
            if (!(S_ISREG(fi->fmodes[i]) && (fi->fflags[i] &
RPMFILE_CONFIG))) {
                fi->actions[i] = FA_REMOVE;
@@ -1379,8 +1379,9 @@
                                fi->fflags, fi->fc * sizeof(*fi->fflags));
            fi->fmodes = memcpy(xmalloc(fi->fc * sizeof(*fi->fmodes)),
                                fi->fmodes, fi->fc * sizeof(*fi->fmodes));
-           fi->fstates = memcpy(xmalloc(fi->fc * sizeof(*fi->fstates)),
-                               fi->fstates, fi->fc *
sizeof(*fi->fstates));
+           if (fi->fstates)
+             fi->fstates = memcpy(xmalloc(fi->fc * sizeof(*fi->fstates)),
+                                  fi->fstates, fi->fc *
sizeof(*fi->fstates));
            fi->dil = memcpy(xmalloc(fi->fc * sizeof(*fi->dil)),
                                fi->dil, fi->fc * sizeof(*fi->dil));
            headerFree(fi->h);

Is that a dangerous way? And maybe you could double check the rebuild db
feature...

Comment 1 Jeff Johnson 1999-12-04 06:04:59 UTC
Your change will work around the problem. The real cause was/is a change in
the way in which filenames are used internally. File states are created only
for packages that contain files, the new representation of filenames caused
filestates not to be created (should not happen), and the segfault occurs
when the packages that were installed with the buggy rpm-3.0.4 are erased.

One way to identify the packages that will exhibit this behavior is to use
	rpm -qa --last
Packages recently installed by rpm-3.0.4 should be upgraded and/or erased.

I also believe this problem is fixed in (at least) rpm-3.0.4-0.4 in Raw Hide


------- Email Received From  Stefan Ring <e9725446@stud3.tuwien.ac.at> 12/04/99 03:08 -------

Comment 2 Jeff Johnson 1999-12-15 17:44:59 UTC
Yes, there might have been bugs in rpm-2.95, as *all* packages in the
database with files should have FILESTATES. I'll probably implement a stronger
check (ala your patch) if the problem seems to be widespread.

Thanks for the patch.


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