Bug 77764 - rpm gets stuck after "Cannot allocate memory"
rpm gets stuck after "Cannot allocate memory"
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
8.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-11-13 02:10 EST by Aleksey Nogin
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-11-13 02:10:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aleksey Nogin 2002-11-13 02:10:52 EST
rpm --root /mnt/tmp -Uvh recode-3.6-6.i386.rpm lftp-2.5.2-5.i386.rpm

got stuck (eating 100% CPU with no activity shown by strace) after printing:

rpmdb: Unable to allocate 4151 bytes from mpool shared region: Cannot allocate
memory
error: db4 error(12) from dbcursor->c_get: Cannot allocate memory
error: error(12) getting "!▒─мшB╕" records from Pubkeys index
warning: recode-3.6-6.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60e
rpmdb: Unable to allocate 4151 bytes from mpool shared region: Cannot allocate
memory
error: db4 error(12) from dbcursor->c_get: Cannot allocate memory
error: error(12) getting "recode" records from Providename index
rpmdb: Unable to allocate 4151 bytes from mpool shared region: Cannot allocate
memory
error: db4 error(12) from dbcursor->c_get: Cannot allocate memory
error: error(12) getting "!▒─мшB╕" records from Pubkeys index
rpmdb: Unable to allocate 4151 bytes from mpool shared region: Cannot allocate
memory
error: db4 error(12) from dbcursor->c_get: Cannot allocate memory
error: error(12) getting "lftp" records from Providename index

Yes, I did do --rebuilddb and it did not help much - I had almost exact same
error installing another package, I removed the __db files and did --rebuilddb,
after which the install succeeded. But as you see above, the problem quickly
came back.

The packages being installed are RedHat's one from the 8.0 release. The -kV on
them (ran before the failed -Uvh attempt) succeeded:

% rpm -Kv recode-3.6-6.i386.rpm lftp-2.5.2-5.i386.rpm
recode-3.6-6.i386.rpm:
    Header V3 DSA signature: OK, key ID db42a60e
    Header SHA1 digest: OK (231cd2851b7fa2237d4d71f1a4ff5d925fb58b20)
    MD5 digest: OK (d6cfc2ca8d2eb879df862b81e91dc38a)
    V3 DSA signature: OK, key ID db42a60e
lftp-2.5.2-5.i386.rpm:
    Header V3 DSA signature: OK, key ID db42a60e
    Header SHA1 digest: OK (e59cb43c0e04dffd3ec3be3e65f176179929a743)
    MD5 digest: OK (4cdbf1ea0b0f3f98ba94f40a416ae526)
    V3 DSA signature: OK, key ID db42a60e

so the "NOKEY" thing is 

P.S. The fs I am doing this on is on NFS, mounted with
rw,v3,rsize=8192,wsize=8192,hard,intr,udp,lock options. NFS client is 8.0, NFS
server is fully up2date'd 7.2.

Note: the -Kv was ran on the same machine as -Uvh, over the same fs, but
NFS-mounted to / instead of /mnt/tmp with the same options, except ro instead of rw.

P.P.S. db4-4.0.14-14 glibc-2.2.93-5 rpm-4.1-1.06
Comment 1 Jeff Johnson 2002-11-15 13:23:32 EST
Berkeley DB doesn't work across NFS *unless* NFS
is set up correctly. Assuming functional NFS, usually
not the case too.

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