Red Hat Bugzilla – Bug 456983
fingerprinting has gone from bad to AIYEEEEE
Last modified: 2014-03-16 23:15:24 EDT
Description of problem:
Fingerprinting gone wild! Available now, free!
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Have some kernels installed, for example:
$ rpm -q kernel-devel
2. Attempt to upgrade kernel-devel, for example, to:
kernel-devel x86_64 2.6.27-0.186.rc0.git15.fc10 rawhide
kernel-devel x86_64 2.6.27-0.156.rc0.git4.fc10 installed
3. There is no step 3.
rpm uses all available memory, grinds the system to a halt, and then falls over
20 minutes later with a 'memory alloc (25102464 bytes) returned NULL' error.
Hmm, I haven't seen any significant difference in fingerprinting (or otherwise)
memory use between 4.4.x and the new version. The fp code is untouched except
for alloca() elimination and such.
I can reproduce rpm memory use exploding on fingerprinting easily enough, but
all the cases I've seen so far explode on both 4.4.x and 4.5.90. It'd be helpful
if you can test whether rpm 4.4.x survives the same operation on same hw and
packageset so I know if I'm actually looking for a regression.
I couldn't reproduce it in a third try, so that's going to make it difficult.
no reproducer != fixed
I can hazard a guess:
Fingerprints are heavily used when multiple kernel-devel packages are installed,
and the malloc assertion failure is dependent on retrieving reliable rpmdb
There's a class of problems with __db* cache inconsistency, and NPTL locking, that have
x86_64 as the only obvious correlate (to me). E.g. see bz #455681 and a long line of other
bug reports from Orion on x86_64. The platform in this report is also "x86_64" judging
from the reported installed rpm version.
Failures with cache inconsistency are dramatically different, and with no simple reproducers, yes.
But there still appears to be a NPTL locking issue with rpmdb's on x86_64 imho.
Have you run into this problem again Bill?
Panu, would you like this to be assigned to you to look at still or should it be closed if Bill can't recreate the problem again?
I believe this has been addressed upstream in a recent commit. I'll reopen if it comes back.
The fingerprinting issue is unlikely to be resolved by any timestamp imposed by bugzilla.
The issue is a fundamental design flaw dating back to RHL 6.0 and rpm-3.0
that is nowhere near being "fixed" anywhere.
Perhaps bugzilla is not the right place to track design flaws in rpm.
But if notting can't reproduce, the symptom was surely cured long ago.