RPM Community Forums

Mailing List Message of <rpm-devel>

malloc returns NULL when using yum

From: Jeff Johnson <n3npq@mac.com>
Date: Wed 14 Jan 2009 - 14:56:45 CET
Message-id: <44A07BDA-1D88-41CE-926F-470804DC6300@mac.com>
Another issue with yum+rpmlib is this:

error: ^(?:([^:-]+):)?([^:-]+)(?:-([^:-]+))?(?::([^:-]+))?$: regexec  
failed: No match(1)
memory alloc (131073 bytes) returned NULL.
==1401== ERROR SUMMARY: 18027 errors from 112 contexts (suppressed: 0  
from 0)
==1401== malloc/free: in use at exit: 45,043,729 bytes in 97,812 blocks.
==1401== malloc/free: 4,116,373 allocs, 4,018,560 frees,  
12,966,246,767 bytes allocated.
==1401== For counts of detected errors, rerun with: -v
==1401== searching for pointers to 97,812 not-freed blocks.
==1401== checked 46,070,400 bytes.

The above was seen on a 1Gb machine with a quite modest upgrade  

A similar issue was reported @rpm.org, yum needing 2.5Gb for an upgrade.
That problem  was diagnosed as memory fragmentation within  
mostly because its inconceivable to most that yum could somehow be  

There's a patch that can do a power of 2 block allocation in  
rpmdbGrowIterator() @rpm.org,
not hard.

The failure is seen only with yum and python, and shows up with yum's  
usage of rpmlib, yum chooses to call rpmtsRun() a second time.

But there's a deeper issue here, memory fragmentation is usually only  
a symptom
of deeper flaws. E.g. the underlying reason why yum is calling  
twice is to detect file conflicts, which really needs to be done earlier
and differently, that's a hysterical design flaw in the rpmlib API from
when transactions were added to RPM in RHL 6.0 in 1999.

However, perhaps there is literally no block of 131073b available. Sad  
if true in 2009.

Dunno, todo++.

73 de Jeff

  • application/pkcs7-signature attachment: smime.p7s
Received on Wed Jan 14 14:56:49 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.