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
==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
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
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.
73 de Jeff
Received on Wed Jan 14 14:56:49 2009
- application/pkcs7-signature attachment: smime.p7s