Bug 108456 - 100% reproducible rpm 4.2.1-0.30 (psuedo)freeze
100% reproducible rpm 4.2.1-0.30 (psuedo)freeze
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
1
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-29 13:31 EST by Barry K. Nathan
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-30 07:52:53 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)
defective redhat-config-network-1.3.10-1.noarch.rpm "package" that freezes rpm -F (5.76 KB, application/octet-stream)
2003-10-29 13:34 EST, Barry K. Nathan
no flags Details

  None (edit)
Description Barry K. Nathan 2003-10-29 13:31:53 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630

Description of problem:
If you attempt to freshen (rpm -F) with a file that's not really an RPM package
but whose name ends with ".rpm", rpm freezes up. It seems to use no CPU time and
appears to just sleep indefinitely. kill -9 seems to be the only recourse.

Version-Release number of selected component (if applicable):
rpm-4.2.1-0.30

How reproducible:
Always

Steps to Reproduce:
1. Download the file I will be attaching.
2. rpm -Fvh redhat-config-network-1.3.10-1.noarch.rpm


Actual Results:
error: open of <!DOCTYPE failed: No such file or directory
error: open of HTML failed: No such file or directory
error: open of PUBLIC failed: No such file or directory
((then it freezes here, with rpm process in S state AFAICT, and no CPU usage
whatsoever))

oh, wait, it just spat out another line after almost 15 minutes of wall clock
time on a 2.4GHz Pentium 4 (FWIW I may have pressed "Control-C" 5-10 minutes
ago, but I don't remember for sure):
error: read failed:  (0)

it still looks frozen, and it has used less than 1 second of CPU time according
to ps


Expected Results:
error: redhat-config-network-1.3.10-1.noarch.rpm: not an rpm package
((command prompt should come back here))


Additional info:

rpm -K handles this case properly (that's where I copied & pasted the "expected
output" from, in fact)
Comment 1 Barry K. Nathan 2003-10-29 13:34:17 EST
Created attachment 95584 [details]
defective redhat-config-network-1.3.10-1.noarch.rpm "package" that freezes rpm -F

This is the file that causes my RPM freeze...
Comment 2 Barry K. Nathan 2003-10-29 13:46:34 EST
Oh, wait, RPM finally finished:
-//W3C//DTD HTML 4.01 Transitional//EN>: not an rpm package (or package manifest):

half an hour on a 2.4GHz Pentium 4 for *one file* is completely unacceptable
performance, though (especially when rpm -K takes a fraction of a second to
accomplish the same amount of work from the user's perspective)
Comment 3 Barry K. Nathan 2003-10-29 13:58:47 EST
Changing summary; "pseudofreeze" is probably a more accurate description.

BTW by "fix may be easy?" I mean that, since rpm -K handles this correctly,
maybe there's some chance that rpm -Fvh can handle it correctly as well.

I'm now trying with 'rpm -ivh', and that's having the same bug.

On a different machine, with rpm 4.2.1-4.2 (recompiled from the SRPM, FWIW),
'rpm -Uvh' also triggers this.
Comment 4 Barry K. Nathan 2003-10-29 14:11:53 EST
Actually I was wrong about it taking half an hour, it's closer to 20 minutes,
but that's still a long long time...
Comment 5 Barry K. Nathan 2003-10-29 14:41:53 EST
The "freeze" does not happen if you do it like this:
rpm -ivh redhat-config-network-1.3.10-1.noarch.rpm < /dev/null

By the way:
(gdb) bt
#0  0xb75ebc32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0xb7395ead in ___newselect_nocancel () from /lib/tls/libc.so.6
#2  0xb746fe40 in fdReadable (fd=0x0, secs=600) at rpmio.c:548
#3  0xb74727c4 in ufdRead (cookie=0x807b1e0, buf=0xbffec434 "", count=96)
    at rpmio.c:1697
#4  0xb75ae65e in readLead (fd=0x807b1e0, lead=0xbffec434) at rpmlead.c:54
#5  0xb75993dc in rpmReadPackageFile (ts=0x8073560, fd=0x807b1e0, 
    fn=0x8070de8 "-//W3C//DTD HTML 4.01 Transitional//EN>", hdrp=0xbfffc584)
    at package.c:761
#6  0xb75acb20 in rpmInstall (ts=0x8073560, ia=0x805b158, fileArgv=0x8069188)
    at rpminstall.c:474
#7  0x0804b489 in main (argc=3, argv=0x0) at rpmqv.c:781

(This is while the RPM process is "frozen" -- actually, waiting for input from
stdin)

Looks like it's waiting for input from stdin! Further experimentation shows that
"rpm -ivh -- -" does this too, for what that's worth...
Comment 6 Jeff Johnson 2003-10-30 07:52:53 EST
Yes, a lonely '-' on the command line means
read from stdin (or write to stdout). This permits
    cat foo*.rpm | rpm -qp -- -

If rpm completed, than stdin was closed.

The real trigger here is HTML crap in the *.rpm
file. Anything that is not a package is interpreted as
a manifest file, whose contents will be parsed and
added to argv.

Don't do that is wisest for now, as it's unclear to
me whether rpm must try to deal with any old random
crapola fed as CLI argument.

Deferred for consideration ...
Comment 7 Ben Smith 2004-09-21 01:17:39 EDT
This also happens with legitimate RPMS.  I get the following output
and the backtrace below from installing
http://download.fedora.us/fedora/fedora/1/i386/RPMS.stable/apt-0.5.15cnc6-0.fdr.11.1.i386.rpm:

# rpm -Uvh /tmp/apt-0.5.15cnc6-0.fdr.11.1.i386.rpm
Preparing...               
########################################### [100%]
NOTE: Default configuration changed!
If you have made any changes to the configuration locally
Merge your local customizations from /etc/apt/apt.conf.rpmsave
to /etc/apt/apt.conf
   1:apt                    warning: /etc/apt/sources.list created as
/etc/apt/sources.list.rpmnew
########################################### [100%]

Then it hangs forever (>20 minutes on a P4 1.8)
It is definitely an rpm.  rpm2cpio handles it fine, and cpio extracts
the archive without complaint.
Backtrace:

#0  0x45195c32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x4543e38e in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0
#2  0x45a6f0ef in __db_pthread_mutex_lock_rpmdb ()
   from /usr/lib/librpmdb-4.2.so
#3  0x45adbfe6 in __lock_get_rpmdb () from /usr/lib/librpmdb-4.2.so
#4  0x45adb8b7 in __lock_get_rpmdb () from /usr/lib/librpmdb-4.2.so
#5  0x45aa089c in __db_c_put_rpmdb () from /usr/lib/librpmdb-4.2.so
Comment 8 Barry K. Nathan 2004-09-21 21:49:07 EDT
Ben, your traceback shows that your bug is completely unrelated to
this one. In your case, something has gone wrong with RPM's locking.
In my case, RPM is waiting for a package to come in via stdin.

Search Bugzilla some more and find a more appropriate bug to add a
comment to, or file a new bug altogether.

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