Bug 456983 - fingerprinting has gone from bad to AIYEEEEE
fingerprinting has gone from bad to AIYEEEEE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-07-28 22:15 EDT by Bill Nottingham
Modified: 2014-03-16 23:15 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-28 15:43:07 EDT
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 Bill Nottingham 2008-07-28 22:15:21 EDT
Description of problem:

Fingerprinting gone wild! Available now, free!

Version-Release number of selected component (if applicable):


How reproducible:

Every time

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       
   5.4 M
 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.
Comment 1 Panu Matilainen 2008-07-30 03:18:14 EDT
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. 
Comment 2 Bill Nottingham 2008-07-30 10:33:20 EDT
I couldn't reproduce it in a third try, so that's going to make it difficult.
Comment 3 Jeff Johnson 2008-08-04 10:08:08 EDT
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.
Comment 4 Christopher D. Stover 2008-10-28 15:31:57 EDT
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?
Comment 5 Bill Nottingham 2008-10-28 15:43:07 EDT
I believe this has been addressed upstream in a recent commit. I'll reopen if it comes back.
Comment 6 Jeff Johnson 2008-10-28 15:43:33 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.