Description of problem: With ncompress-4.2.4-33 and -38, we're seeing the following behavior on zSeries: .qa.[root@kryten jkt]# ls -l anaconda -rwxr-xr-x 1 root root 31093 Apr 22 16:04 anaconda .qa.[root@kryten jkt]# file anaconda anaconda: a /usr/bin/python2.2 script text executable .qa.[root@kryten jkt]# compress anaconda .qa.[root@kryten jkt]# ls -l anaconda.Z -rwxr-xr-x 1 root root 14955 Apr 22 16:04 anaconda.Z .qa.[root@kryten jkt]# file anaconda.Z anaconda.Z: compress'd data block compressed 16 bits .qa.[root@kryten jkt]# uncompress anaconda.Z .qa.[root@kryten jkt]# ls -l anaconda -rwxr-xr-x 1 root root 9586 Apr 22 16:04 anaconda .qa.[root@kryten jkt]# file anaconda anaconda: data Doing a little rooting around, it actually appears that it's "compress" which is doing the evil, as if I dropped a known-good compressed file in there and uncompress it, all is well. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
(aside) This is file problem: .qa.[root@kryten jkt]# file anaconda anaconda: a /usr/bin/python2.2 script text executable So the problem is 31093 != 9586 ? FYI, the only change in ncompress -38 is s/long/long long/ easily reverted if not perfect.
Nah, thought znaconda.Z, not anacoda. never nind.
I haven't dug in too deeply, but am seeing this with -33 as well, so I suspect the problem goes back quite a ways before -38.
I tested compress with a couple of files. The resulting compressed file is the expected size. That is, it is the same size that I get when I compress the original file on an x86 system. The first three bytes are 0x1f 0x9d 0x90 (the compress magic number) but the rest of the bytes are null. A 31-bit compress binary (from the s390 RPM) produces valid output. This is pretty clearly a problem with the size of a "int" or "long int" coupled with not handling endian-ness correctly. I built the ncompress-4.2.4-44.1 source RPM from RHEL5 beta but it behaves the same. I've traced this to sizeof(long) == 8 in the s390x environment coupled with the little endian byte order. Replacing union bytes { long word; with union bytes { int word; results in a compress(1) command that produces correct output. The compress(1) command produces the same invalid output on PowerPC-64 (ppc64) if compiled from source and the "-m64" compiler switch is employed. The only reason this hasn't been reported as a problem on ppc64 appears to be that a 32- bit version of the program is installed. This problem will affect any version of compress(1) compiled on a 64-bit little- endian architecture where sizeof(long) == 4.
Argh! My last sentence should say "problem will affect ... 64-bit little-endian achitecture where sizeof(long) == 8.
QE ack for RHEL3.9. Dup'ing for RHEL4 and RHEL5 as well.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0413.html