Bug 212959 - compress/uncompress not working well on 64-bit little-endian platforms
compress/uncompress not working well on 64-bit little-endian platforms
Status: CLOSED DUPLICATE of bug 207124
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: ncompress (Show other bugs)
4.4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
Ben Levenson
:
Depends On: 131132
Blocks: 212960
  Show dependency treegraph
 
Reported: 2006-10-30 06:58 EST by Jay Turner
Modified: 2015-01-07 19:14 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-30 07:49:28 EST
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 2006-10-30 06:58:13 EST
+++ This bug was initially created as a clone of Bug #131132 +++

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:

-- Additional comment from jbj@redhat.com on 2004-08-27 16:36 EST --
(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.

-- Additional comment from jbj@redhat.com on 2004-08-27 19:23 EST --
Nah, thought znaconda.Z, not anacoda. never nind.

-- Additional comment from jturner@redhat.com on 2004-08-27 21:03 EST --
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.

-- Additional comment from kdrader@us.ibm.com on 2006-09-15 23:37 EST --
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.


-- Additional comment from kdrader@us.ibm.com on 2006-09-15 23:59 EST --
Argh! My last sentence should say "problem will affect ...

    64-bit little-endian achitecture where sizeof(long) == 8.


-- Additional comment from jturner@redhat.com on 2006-10-30 06:51 EST --
QE ack for RHEL3.9.  Dup'ing for RHEL4 and RHEL5 as well.
Comment 1 Jay Turner 2006-10-30 06:59:11 EST
I'm able to reproduce this on a RHEL4 box with ncompress-4.2.4-43.rhel4.s390x.
Comment 2 RHEL Product and Program Management 2006-10-30 07:04:14 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 3 Peter Vrabec 2006-10-30 07:49:28 EST

*** This bug has been marked as a duplicate of 207124 ***

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