Bug 143782

Summary: rpm 4.4.1 - rpmfcClassify: Assertion `ftype != ((void *)0)' failed
Product: [Fedora] Fedora Reporter: Robert Scheck <redhat-bugzilla>
Component: fileAssignee: Radek Vokál <rvokal>
Status: CLOSED WONTFIX QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: nobody+pnasrat
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-03-07 13:23:55 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 Robert Scheck 2004-12-27 19:30:13 UTC
Description of problem:
Building of a RPM package using 4.4.1-0.4 from ftp.jbj.org dies 
with the following:

--- snipp ---
Processing files: mod_perl-1.99_19-0
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.28309
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd mod_perl-1.99_19
+ DOCDIR=/var/tmp/mod_perl-root/usr/share/doc/mod_perl-1.99_19
+ export DOCDIR
+ rm -rf /var/tmp/mod_perl-root/usr/share/doc/mod_perl-1.99_19
+ /bin/mkdir -p /var/tmp/mod_perl-root/usr/share/doc/mod_perl-1.99_19
+ cp -pr Changes INSTALL LICENSE README docs /var/tmp/mod_perl-root/usr/share/doc/mod_perl-1.99_19
+ exit 0
error: magic_file(ms, "/var/tmp/mod_perl-root/usr/share/doc/mod_perl-1.99_19/docs/user/handlers/connection_cycle.dia") faileds: gzip compressed data, from Unix
rpmbuild: rpmfc.c:1224: rpmfcClassify: Assertion `ftype != ((void *)0)' failed.
Abgebrochen [means something like 'aborted']
--- snapp ---

'ls -l' to the file:
-rw-r--r--    1 root     root         2312 Nov 29 19:40 /var/tmp/mod_perl-root/usr/share/doc/mod_perl-1.99_19/docs/user/handlers/connection_cycle.dia

'file' to the file:
/var/tmp/mod_perl-root/usr/share/doc/mod_perl-1.99_19/docs/user/handlers/connection_cycle.dia: gzip compressed data, from Unix

Version-Release number of selected component (if applicable):
rpm-4.4.1-0.4

How reproducible:
Everytime, see below.

Steps to Reproduce:
1. Take mod_perl-1.99_17-1 from Rawhide
2. Bump version tag to _19 and release tag to whatever you like
3. Change Source0's URL, that it matches for -2.0.0-RC2-XMas
4. Add to %setup -q the string "-n %{name}-2.0.0-RC2-XMas" 
5. Try to build the RPM. 
6. Die with the error written above.
  
Actual results:
No rpm was built.

Expected results:
A rpm should be built.

Additional info:
Hope, you've had nice holidays, jbj ;-)

Comment 1 Robert Scheck 2004-12-27 19:42:08 UTC
Oh, I forgot to say, that it seems, that the problem was introduced 
with rpm 4.4.x, because my rebuild using rpm 4.3.x went fine. Hope
that helps you.

Comment 2 Jeff Johnson 2004-12-29 11:38:02 UTC
Ptr to *.src.rpm please.

Comment 3 Robert Scheck 2004-12-29 16:15:10 UTC
http://labs.linuxnetz.de/bugzilla/mod_perl-1.99_19-0.src.rpm
MD5SUM: 1098a7880088a9b4585fb88a42cdd502

Comment 4 Robert Scheck 2005-01-03 13:10:52 UTC
[03:26:51] < jbj> rsc: #143782 solved. turns out libmagic equiv of 
file -z is a bit dain bread, nuking MAGIC_COMPRESS fixes mod_perl. 
perhaps connection_cycle.dia needs re-compress. no matter what, 
libmagic is a bit stupid about partial block uncompresses. 
[13:48:57] < jbj> rsc_: rpm-4.4.1 was attempting equivalent of 
file(1) -z to identify what was compressed. doesn't work, don't do 
that was the fix.

Changelog of rpm-4.4.1-0.5 contains:
- revert MAGIC_COMPRESS, real fix is in libmagic (#143782).

So does a bug report for libmagic exist?

Comment 5 Jeff Johnson 2005-01-03 13:45:24 UTC
Re-assigned to file.

Comment 6 Jeff Johnson 2005-01-03 13:49:05 UTC
file -z .../connection_cycle.dia (from the mod_perl package)
is a reproducer, look for " ... ERROR: ..." in the output.

Comment 7 Radek Vokál 2005-01-05 12:00:36 UTC
Well, what kind of files are these? There sth rotten. I've renamed the
files to unzip them. First let's see that the bug is still here

# file *.gz
bucket_brigades.dia.gz:  gzip compressed data, from Unix
connection_cycle.dia.gz: gzip compressed data, from Unix

# file -z *.gz
bucket_brigades.dia.gz:  XML document text (gzip compressed data, from
Unix)
connection_cycle.dia.gz: ERROR: gzip compressed data, from Unix

And now unzip .. Seems to be broken..

# gunzip connection_cycle.dia.gz
gunzip: connection_cycle.dia.gz: invalid compressed data--crc error
gunzip: connection_cycle.dia.gz: invalid compressed data--length error

Hmm, but I can view the file in midnight commander so I tried

# zcat connection_cycle.dia.gz

some xml stuff, but at the end I can still see this

zcat: connection_cycle.dia.gz: invalid compressed data--crc error
zcat: connection_cycle.dia.gz: invalid compressed data--length error

So writing the data to another file

# zcat connection_cycle.dia.gz > test.dia
zcat: connection_cycle.dia.gz: invalid compressed data--crc error
zcat: connection_cycle.dia.gz: invalid compressed data--length error

Zipping it

# gzip test.dia
# file -z test.dia.gz
test.dia.gz: XML document text (gzip compressed data, was "test.dia",
from Unix)

Here I go, the `file` seems to be fine but the file seems broken to me. 

Comment 8 Robert Scheck 2005-01-28 18:25:26 UTC
Rebuilding of MAKEDEV-3.3.12.3-1.src.rpm (from Red Hat Enterprise 
Linux 3 or clones) using rpm-4.4.1-0.7 also fails with the same error, 
but here at the file /var/tmp/MAKEDEV-root/dev/adbmouse :-(

Comment 9 Jeff Johnson 2005-01-28 18:54:23 UTC
zcat (from gzip) and zlib are similar but different forms of
compression. Don't be tricked.

You are almost certainly correct that the file is strangely
compressed.

However,  the real issue is file and -z handling through libmagic, not
the strangely compressed file. file has flip-flopped from using a gzip
pipe to using zlib several times over the years.

zlib is arguably more efficient than a gzip pipe.

And "ERROR" should not be returned in-band within the libmagic buffer
no matter whether gzip pipe or zlib linkage is used by file.

Does that clarify the problem?

Comment 11 Robert Scheck 2005-01-31 16:39:51 UTC
Ignore comment #8 please, this is bug #146623 - but with the same
error message.

Comment 12 Radek Vokál 2005-03-07 13:23:55 UTC
I think the file output is correct so I don't see a problem here. The
ERROR is returned because the file which it is trying to uncompress is
broken - what kind of output do you expect here while it has to say
that there's sth rotten in the file.