Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 131132 - compress/uncompress not working well on zSeries
compress/uncompress not working well on zSeries
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: ncompress (Show other bugs)
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:
Last Closed: 2007-06-11 14:52:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0413 normal SHIPPED_LIVE ncompress bug fix update 2007-06-07 15:22:13 EDT

  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:
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;


    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.


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