Bug 77764 - rpm gets stuck after "Cannot allocate memory"
Summary: rpm gets stuck after "Cannot allocate memory"
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 8.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-11-13 07:10 UTC by Aleksey Nogin
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-11-13 07:10:59 UTC
Embargoed:


Attachments (Terms of Use)

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 "!▒─мш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 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.


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