Bug 77764

Summary: rpm gets stuck after "Cannot allocate memory"
Product: [Retired] Red Hat Linux Reporter: Aleksey Nogin <aleksey>
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED NOTABUG QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 8.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-11-13 07:10:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Aleksey Nogin 2002-11-13 07:10:52 UTC 
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 "!&#9618;&#9472;&#1084;&#1096;B&#9557;" 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 "!&#9618;&#9472;&#1084;&#1096;B&#9557;" 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 18:23:32 UTC 
Berkeley DB doesn't work across NFS *unless* NFS
is set up correctly. Assuming functional NFS, usually
not the case too.