|Summary:||RPM blows alloc and crashes; apparently also blows update|
|Product:||[Retired] Red Hat Linux||Reporter:||Need Real Name <steve.masticola>|
|Component:||rpm||Assignee:||Jeff Johnson <jbj>|
|Status:||CLOSED RAWHIDE||QA Contact:||David Lawrence <dkl>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2001-08-02 17:37:40 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Need Real Name 2001-07-31 19:06:28 UTC
From Bugzilla Helper: User-Agent: Mozilla/4.75 [en] (Windows NT 5.0; U) Description of problem: RPM tries to allocate two plus billion (with a B) bytes of memory. One example: [root@localhost /root]# rpm -ivh --replacepkgs /cdrom/RedHat/RPMS/kdeadmin-2.1.1-3.i386.rpm Preparing... memory alloc (2237676289 bytes) returned NULL. [root@localhost /root]# This apparently also blows the update from CDROM process. Please let me know what I can do, short of a full reinstall of my whole box. Thanks, - Steve. How reproducible: Always Steps to Reproduce: 1. Mount the Red Hat distro disk on my box. 2. Execute "rpm -ivh --replacepkgs" as root. 3. Actual Results: /cdrom/RedHat/RPMS/kdeadmin-2.1.1-3.i386.rpm Preparing... memory alloc (2237676289 bytes) returned NULL. Expected Results: At a guess, rpm should have completed without core dumping. Additional info: This is preventing me from upgrading anything without wiping the system and it's hitting other people too. Search groups.google.com for "rpm memory linux" and you'll find several other fairly recent (summer 2001) examples of the same bug. Another symptom is that rpm --rebuilddb hangs, using 99% of available CPU and making no disk traffic.
Comment 1 Jeff Johnson 2001-07-31 19:12:12 UTC
What rpm package version-release? Try rpm-4.0.3 ... FWIW, the malloc failure is almost always a damaged package and/or database header. Have you tried a rpm --rebuilddb?
Comment 2 Need Real Name 2001-07-31 19:49:03 UTC
Don't know which version/release. It was whatever came with RH 7.1. I'll check tonight. I did try rpm --rebuilddb. It busy-waited for 30 minutes, making no disk accesses and soaking up 99% of CPU. I killed it. - Steve.
Comment 3 Jeff Johnson 2001-07-31 19:59:52 UTC
You might also try "rpm -K" on the package that you are trying to install, that should catch size problems. Meanwhile, I suspect that you have a rpm database problem. A --rebuilddb with rpm-4.0.3 from Raw Hide should fix that. Rather than wait 30 minutes, try adding -vv to see progress during a rebuilddb.
Comment 4 Need Real Name 2001-08-01 01:33:31 UTC
This is going to be a dumb question, but where on rawhide is rpm-4.0.3? I scouted through a lot of it and found nothing later than 4.0.2 (in rpm format, of course, so I don't know if I could even have installed it with the ROM database busted!) Thanks, - Steve.
Comment 5 Need Real Name 2001-08-01 04:16:37 UTC
Ignore previous question. I found rpm-4.0.3. A few more data points: I've got RPM 4.0.2 on this box. (How much real difference is there between 4.0.2 and 4.0.3? I t looks like it's going to be a PITA to put 4.0.3 up due to dependencies, conflicts in the dependencies, etc.) Here's where rpm --rebuilddb --vv is hanging: D: +++ 389 kdelibs-sound-devel-2.1.1-5 D: adding "kdelibs-sound-devel" to Name index. D: adding 74 entries to Basenames index. D: adding "Development/Libraries" to Group index. D: adding 17 entries to Requirename index. D: adding 1 entries to Providename index. D: +++ 390 kdevelop-1.4.1-2 D: adding "kdevelop" to Name index. D: adding 1309 entries to Basenames index. D: adding "Development/Tools" to Group index. D: adding 52 entries to Requirename index. D: adding 1 entries to Providename index. D: adding 1 entries to Conflictname index. So at a guess the corruption is in the kdevelop package. I tried to erase kdevelop, but got the following error: [root@localhost steve]# rpm --erase kdevelop-1.4.1-2 -vv D: opening db index /var/lib/rpm/Packages mode=0x82 D: locked db index /var/lib/rpm/Packages D: opening db index /var/lib/rpm/Name mode=0x82 D: opening db index /var/lib/rpm/Requirename mode=0x82 D: getting list of mounted filesystems D: opening db index /var/lib/rpm/Basenames mode=0x82 D: opening db index /var/lib/rpm/Group mode=0x82 D: opening db index /var/lib/rpm/Providename mode=0x82 D: opening db index /var/lib/rpm/Conflictname mode=0x82 D: opening db index /var/lib/rpm/Triggername mode=0x82 D: opening db index /var/lib/rpm/Depends create mode=0x82 memory alloc (2237676289 bytes) returned NULL. [root@localhost steve]# What next? Thanks, - Steve.
Comment 6 Jeff Johnson 2001-08-01 12:34:32 UTC
Send me a pointer (i.e. URL, bugzilla attachments won't work) to a tarball of your database cd /var/lib tar czvf /tmp/rpmdb.tar.gz rpm and I'll take a look.
Comment 7 Need Real Name 2001-08-02 14:00:28 UTC
The tarball is available for anonymous FTP at ftp.scr.siemens.com. This site doesn't display directories to FTP, but I've verified that it is there. Please let me know when you have it so that I can delete it. Thanks, - Steve. P.S. I've also noticed several directories under /var/lib: RPMREBUILDDB.1182/ RPMREBUILDDB.1190/ RPMREBUILDDB.1189/ RPMREBUILDDB.6919/ (CDROM burner messed up the case.) If you think they'd be useful, please let me know. -S.
Comment 8 Jeff Johnson 2001-08-02 16:54:06 UTC
Full URL of file please, as here's what I see: bash$ ncftpget ftp://ftp.scr.siemens.com/rpmdb.tar.gz ncftpget: server said: rpmdb.tar.gz: No such file or directory. rpm --rebuilddb builds into a temp directory, if the rebuild fails, the temp directory is left behind. Nuke the directories at your convenience.
Comment 9 Need Real Name 2001-08-02 17:27:50 UTC
Sorry, I forgot that you can't log in as anonymous to retrieve files off this directory. I'll send you instructions by separate mail for security reasons. If Earthlink hadn't messed up my space allocations, I'd have had this done hours ago. Thanks, -S.
Comment 10 Need Real Name 2001-08-02 17:37:36 UTC
Apart from the username and password I sent you by separate mail, the URL would be ftp://ftp.scr.siemens.com/incoming/rpmdb.tar.gz You must specify the username and password, a la' ftp ftp.scr.siemens.com [Nastygram] Name (ftp.scr.siemens.com:masticol): <username> 331 Password required for <username> Password: <password> ftp> hash Hash mark printing on (1024 bytes/hash mark). ftp> bin 200 Type set to I. ftp> get rpmdb.tar.gz 200 PORT command successful. 150 Opening BINARY mode data connection for rpmdb.tar.gz (5740494 bytes). ################################################################################ [a lot of times] 226 Transfer complete. 5740494 bytes received in 9.6 seconds (5.9e+02 Kbytes/s) ftp> - Steve.
Comment 11 Jeff Johnson 2001-08-02 18:33:49 UTC
The database problem has been fixed in private e-mail. Please reopen this bug if not.