[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

non-deterministic compression results with gzip -n9

From: Riku Voipio
Subject: non-deterministic compression results with gzip -n9
Date: Thu, 8 Dec 2011 12:27:38 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hi (please CC:, not on list),

It has been observed in Debian and Ubuntu that the results of gzip -n9
are not deterministic. This appears to be an heisenbug, that is not usually
reproducible. The attached two files decompress to the same file. Both files
were created on ubuntu with gzip 1.3.12-9ubuntu1.1, but similar behaviour
has been observed with gzip 1.4 on ubuntu and debian. Bigger file was created
on a x86_64 system, but on my x86_64 system I haven't been able to reproduce
it. The diffences appear on the last 10 bytes:

$ cmp -l ChangeLog.pre-2-2.amd64.gz ChangeLog.pre-2-2.armel.gz
17375 126 122
17376 327  13
17377 327 377
17378 377  37
17379  37 155
17380 155  57
17381  57 155
17382 155  56
17383  56 324
17384 324 301
17385 301   0
cmp: EOF on ChangeLog.pre-2-2.armel.gz

The other sample is different only on the last 3 bytes:

$ cmp -l NEWS.amd64.gz NEWS.armel.gz
5110 207 367
5111  56 120
5113  13  27

According to gzip RFC, the last 4 bytes are ISIZE, which should be
uncompressed input size. Which leaves me rather baffled how that can
differ on same input files - and how gunzip is completly happy with
both versions of compressed file, producing the same output.

Any help debugging deeper would be appreceated.



Original bugreport:


Attachment: ChangeLog.pre-2-2.amd64.gz
Description: Binary data

Attachment: ChangeLog.pre-2-2.armel.gz
Description: Binary data

Attachment: NEWS.amd64.gz
Description: Binary data

Attachment: NEWS.armel.gz
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]