Bug 131132

Summary: compress/uncompress not working well on zSeries
Product: Red Hat Enterprise Linux 3 Reporter: Jay Turner <jturner>
Component: ncompressAssignee: Peter Vrabec <pvrabec>
Status: CLOSED ERRATA QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: dkovalsk, srevivo
Target Milestone: ---   
Target Release: ---   
Hardware: s390x   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2007-0413 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-06-11 18:52:21 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:
Bug Depends On:    
Bug Blocks: 212959    

Description Jay Turner 2004-08-27 20:16:22 UTC 
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:
Comment 1 Jeff Johnson 2004-08-27 20:36:26 UTC 
(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.
Comment 2 Jeff Johnson 2004-08-27 23:23:02 UTC 
Nah, thought znaconda.Z, not anacoda. never nind.
Comment 3 Jay Turner 2004-08-28 01:03:37 UTC 
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.
Comment 4 Kurtis Rader 2006-09-16 03:37:20 UTC 
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.
Comment 5 Kurtis Rader 2006-09-16 03:59:59 UTC 
Argh! My last sentence should say "problem will affect ...

    64-bit little-endian achitecture where sizeof(long) == 8.
Comment 6 Jay Turner 2006-10-30 11:51:25 UTC 
QE ack for RHEL3.9.  Dup'ing for RHEL4 and RHEL5 as well.
Comment 11 Red Hat Bugzilla 2007-06-11 18:52:22 UTC 
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