Bug 7573
| Summary: | rpm dumps core when RPMTAG_FILESTATES is missing | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Raw Hide | Reporter: | sring |
| Component: | rpm | Assignee: | Jeff Johnson <jbj> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1.0 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 1999-12-15 17:44:12 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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.ac.at> 12/04/99 03:08 ------- 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. |
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...