Red Hat Bugzilla – Bug 35827
rpmtransAddPackage() seems to make bogus ordering assumption
Last modified: 2007-04-18 12:32:39 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.17-14 i686)
rpmtransAddPackage() removes packages obsoleted by the package being
added. In order to prevent duplicate removal, it calls
rpmdbPruneIterator() with the transaction's existing removed package list.
The fourth argument to rpmdbPruneIterator() is 1, asserting that the
pruning list is sorted; however, there does not appear to be any guarantee
that the list is in fact sorted; removePackage() does not add dboffset in
sorted order, nor is there a sort of the list somewhere in
As a result, a package could be removed twice (which causes a silent error
rpmRunTransactions()) due to failure to properly prune the set.
Reproducible: Didn't try
Steps to Reproduce:
I noticed this problem by reading the source code, not by actually
encountering it. Reliably producing the problem would be somewhat
complicated because it is difficult to predict offsets of packages in the
database, and bsearch() might find something in an unsorted list if it is
Yup, another good call, thanks. Fixed by moving the qsort from rpmdepCheck to
removePackage in rpm-4.0.3-0.22.