Bug 131132 - compress/uncompress not working well on zSeries
compress/uncompress not working well on zSeries
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: ncompress (Show other bugs)
3.0
s390x Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
Ben Levenson
:
Depends On:
Blocks: 212959
  Show dependency treegraph
 
Reported: 2004-08-27 16:16 EDT by Jay Turner
Modified: 2015-01-07 19:08 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2007-0413
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-11 14:52:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jay Turner 2004-08-27 16:16:22 EDT
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 16:36:26 EDT
(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 19:23:02 EDT
Nah, thought znaconda.Z, not anacoda. never nind.
Comment 3 Jay Turner 2004-08-27 21:03:37 EDT
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-15 23:37:20 EDT
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-15 23:59:59 EDT
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 06:51:25 EST
QE ack for RHEL3.9.  Dup'ing for RHEL4 and RHEL5 as well.
Comment 11 Red Hat Bugzilla 2007-06-11 14:52:22 EDT
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

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