Description of problem: Fingerprinting gone wild! Available now, free! Version-Release number of selected component (if applicable): rpm-4.5.90-0.git8426.9.x86_64 How reproducible: Every time Steps to Reproduce: 1. Have some kernels installed, for example: $ rpm -q kernel-devel kernel-devel-2.6.25.6-55.fc9.x86_64 kernel-devel-2.6.27-0.156.rc0.git4.fc10.x86_64 kernel-devel-2.6.27-0.159.rc0.git6.fc10.x86_64 kernel-devel-2.6.27-0.166.rc0.git8.fc10.x86_64 2. Attempt to upgrade kernel-devel, for example, to: Installing: kernel-devel x86_64 2.6.27-0.186.rc0.git15.fc10 rawhide 5.4 M Removing: kernel-devel x86_64 2.6.27-0.156.rc0.git4.fc10 installed 34 M 3. There is no step 3. Actual results: 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. Expected results: Not that.
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 data. 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.