Bug 143782 - rpm 4.4.1 - rpmfcClassify: Assertion `ftype != ((void *)0)' failed
Summary: rpm 4.4.1 - rpmfcClassify: Assertion `ftype != ((void *)0)' failed
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: file
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Radek Vokál
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-12-27 19:30 UTC by Robert Scheck
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-03-07 13:23:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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. 


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