Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 7573 - rpm dumps core when RPMTAG_FILESTATES is missing
rpm dumps core when RPMTAG_FILESTATES is missing
Product: Red Hat Raw Hide
Classification: Retired
Component: rpm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Depends On:
  Show dependency treegraph
Reported: 1999-12-03 18:52 EST by sring
Modified: 2008-05-01 11:37 EDT (History)
0 users

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

Attachments (Terms of Use)

  None (edit)
Description sring 1999-12-03 18:52:07 EST
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]))
-           if (fi->fstates[i] != RPMFILE_STATE_NORMAL)
+           if (fi->fstates && fi->fstates[i] != RPMFILE_STATE_NORMAL)
            if (!(S_ISREG(fi->fmodes[i]) && (fi->fflags[i] &
                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 *
+           if (fi->fstates)
+             fi->fstates = memcpy(xmalloc(fi->fc * sizeof(*fi->fstates)),
+                                  fi->fstates, fi->fc *
            fi->dil = memcpy(xmalloc(fi->fc * sizeof(*fi->dil)),
                                fi->dil, fi->fc * sizeof(*fi->dil));

Is that a dangerous way? And maybe you could double check the rebuild db
Comment 1 Jeff Johnson 1999-12-04 01:04:59 EST
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 12:44:59 EST
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.