zlib crc32 problems

ozanbaba · 04-12-2022, 01:19 AM

Hello All,
I wanted to drop some information about this. AS far as I know, this does not affect a lot of applications but there are several bug reports in zlib issues page. The basic explanation is that the behaviour of crc32 changed between 1.2.11 and 1.2.12 which broke calculations. (OK actually it works more strict.) Because of the affect, they bought back the old behaviour back. Details about what they did is in this commit.
From the comments I read, they plan to do a new release soon.

Regards,
Ozan

luvr · 04-12-2022, 06:33 AM

Quote:

Originally Posted by ozanbaba

Hello All,
I wanted to drop some information about this. AS far as I know, this does not affect a lot of applications but there are several bug reports in zlib issues page. The basic explanation is that the behaviour of crc32 changed between 1.2.11 and 1.2.12 which broke calculations. (OK actually it works more strict.) Because of the affect, they bought back the old behaviour back. Details about what they did is in this commit.
From the comments I read, they plan to do a new release soon.

Regards,
Ozan

Strange problem, isn’t it? I have trouble wrapping my head around the idea that an application may pass garbage into some part of a value (and that part doesn’t even have any meaning to the called function), and won’t run into problems later on when who knows what garbage it has dumped there at that time. But then, I don’t really know what I’m talking about here, anyway. (If I did, then I guess I would understand why such garbage won’t hurt in this specific case.

)

luvr · 04-20-2022, 01:55 PM

Quote:

Originally Posted by ozanbaba

Hello All,
I wanted to drop some information about this. AS far as I know, this does not affect a lot of applications but there are several bug reports in zlib issues page. The basic explanation is that the behaviour of crc32 changed between 1.2.11 and 1.2.12 which broke calculations. (OK actually it works more strict.) Because of the affect, they bought back the old behaviour back. Details about what they did is in this commit.
From the comments I read, they plan to do a new release soon.

Regards,
Ozan

I can confirm that, with the patch, zlib works correctly again—at least when it comes to building the openjdk7 SlackBuild. I had kept the failing SlackBuild around and, after I rebuilt zlib with the patch included, I retried the “jar” command that failed. In actual fact, the failing command was a jar “update”, so I first ran the preceding jar “create”:

Code:

/tmp/SBo/openjdk7/icedtea-build/bootstrap/jdk1.6.0/bin/jar \
   cf \
   /tmp/SBo/openjdk7/icedtea-build/openjdk.build/hotspot/outputdir/linux_amd64_compiler2/product/../generated/sa-jdi.jar \
   -C /tmp/SBo/openjdk7/icedtea-build/openjdk.build/hotspot/outputdir/linux_amd64_compiler2/product/../generated/saclasses/ \
   .

Then came the jar “update”:

Code:

/tmp/SBo/openjdk7/icedtea-build/bootstrap/jdk1.6.0/bin/jar \
   uf \
   /tmp/SBo/openjdk7/icedtea-build/openjdk.build/hotspot/outputdir/linux_amd64_compiler2/product/../generated/sa-jdi.jar \
   -C \
   /tmp/SBo/openjdk7/icedtea-build/openjdk/hotspot/agent/src/share/classes META-INF/services/com.sun.jdi.connect.Connector

Without the patch, a Java “ZipException” is the result:

Code:

java.util.zip.ZipException: invalid entry CRC (expected 0x3943b2a7 but got 0xc7a06d31)
	at java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:413)
	at java.util.zip.ZipInputStream.read(ZipInputStream.java:195)
	at java.io.FilterInputStream.read(FilterInputStream.java:107)
	at sun.tools.jar.Main.copy(Main.java:822)
	at sun.tools.jar.Main.update(Main.java:584)
	at sun.tools.jar.Main.run(Main.java:224)
	at sun.tools.jar.Main.main(Main.java:1231)

With the patch, the jar file gets correctly generated.