Description of problem: Is possible that some java applications fail to work due some changes in zlib A example is JDownlader from http://installer.jdownloader.org/JDownloader.jar Version-Release number of selected component (if applicable): zlib-1.2.12-1.mga8.src.rpm java-11-openjdk-11.0.13.0.8-2.1.mga8.src.rpm How reproducible: In a 64bit system with mageia 64bit (i586 strangely is not affected) Steps to Reproduce: 1.Download the jar 2. In console java -jar JDownloader.jar 3. The application fail to install their components and you can see the next message on the console org.jdownloader.update.UpdateManager.log 06/04/22 12:23:39 - SEVERE [ org.jdownloader.update.UpdateManager.log ] -> Exception thro wn at org.jdownloader.update.DefaultCallbackHandler.handleException(DefaultCallbackHandler.java:243): org.appwork.updatesys.client.InstallException: org.tukaani.xz.CorruptedInputException: XZ Index is corrupt at org.appwork.updatesys.client.InstallException.wrap(InstallException.java:24) at org.appwork.updatesys.client.UpdateClient.runPackageExtraction(UpdateClient.java:4063) at org.jdownloader.update.UpdateManager.runUpdateLoop(UpdateManager.java:1227) at org.jdownloader.update.PendingUpdate.run(PendingUpdate.java:19) at org.jdownloader.update.UpdateManager$23.run(UpdateManager.java:1666) at java.base/java.lang.Thread.run(Thread.java:829) Caused by: org.tukaani.xz.CorruptedInputException: XZ Index is corrupt at org.tukaani.xz.index.IndexHash.validate(Unknown Source) at org.tukaani.xz.SingleXZInputStream.read(Unknown Source) at org.tukaani.xz.XZInputStream.read(Unknown Source) at java.base/java.io.InputStream.read(InputStream.java:205) at org.appwork.updatesys.client.UpdateClient.runPackageExtraction(UpdateClient.java:4039) ... 4 more WorkArrounds: 1. Download precompiled java binaries from oracle (openjdk ones don't works) and use the java from oracle to run JDownloader or the afected java application or 2. As root downgrade to lib64zlib1-1.2.11-9 urpmi --downgrade lib64zlib1-1.2.11-9.mga8
Our openjdk probably needs to be updated too.
Assignee: bugsquad => java
I've submitted a zlib-1.2.12-1.1.mga8 to updates_testing with a potential fix
(In reply to Thomas Backlund from comment #2) > > I've submitted a zlib-1.2.12-1.1.mga8 to updates_testing with a potential > fix Due something needed i also have to install the devel flavour, look like solve the reported issue, some other test to do to see if no broke other thing?
Advisory: The zlib update to 1.2.12 done as part of security update MGASA-2022-0124 introduced stricter handling of incorrect CRC inputs with bits set above the low 32. Unfortunately this broke some applications that uses buggy coding like that. Even if those applications (many that are not provided by Mageia) need to be fixed, the reality is that it will take time, and some older legacy applications will probably never be fixed. This update restores previous behaviour of being less strict in order to allow the applications to work as before the zlib 1.2.12 update. SRPM: zlib-1.2.12-1.1.mga8.src.rpm i586: libminizip1-1.2.12-1.1.mga8.i586.rpm libminizip-devel-1.2.12-1.1.mga8.i586.rpm libzlib1-1.2.12-1.1.mga8.i586.rpm libzlib-devel-1.2.12-1.1.mga8.i586.rpm libzlib-static-devel-1.2.12-1.1.mga8.i586.rpm x86_64: lib64minizip1-1.2.12-1.1.mga8.x86_64.rpm lib64minizip-devel-1.2.12-1.1.mga8.x86_64.rpm lib64zlib1-1.2.12-1.1.mga8.x86_64.rpm lib64zlib-devel-1.2.12-1.1.mga8.x86_64.rpm lib64zlib-static-devel-1.2.12-1.1.mga8.x86_64.rpm
Assignee: java => qa-bugs
(In reply to Thomas Backlund from comment #4) Would be good give some feedback on upstream report https://github.com/madler/zlib/issues/426 , could you do it? or tell me what to "say" ?
(In reply to katnatek from comment #5) > (In reply to Thomas Backlund from comment #4) > Would be good give some feedback on upstream report > https://github.com/madler/zlib/issues/426 , could you do it? or tell me what > to "say" ? Just point out to them that the fix from devel branch: https://github.com/madler/zlib/commit/ec3df00224d4b396e2ac6586ab5d25f673caa4c2 is needed in master branch to fix up 1.2.12 for this issue...
(In reply to Thomas Backlund from comment #6) Done! Thank you
My first attempt to reproduce the situation from Comment 0 was in a VirtualBox guest. I did not see the issue there. A bit of investigation revealed that BOTH the 64-bit and 32-bit versions of libzlib1 were installed, I have no idea when this happened - possibly at installation. Using the netinstall iso to do the install, it is more than possible that I activated the 32-bit repos as well as the 64-bit ones. Switching to real hardware that didn't have the 32-bit version installed, I reproduced the fault. It would seem that another workaround for the original situation could have been to install the 32-bit version of libzlib1. I updated using qarepo, with no installation issues. After the update, the problem from Comment 0 disappeared. In addition, as in Bug 30204, I ran Ark and Handbrake with no issues. I don't know what, if anything, needs to be done about the difference between the 32-bit and 64-bit versions, but that is something to be addressed in a different bug. Giving this an OK, and validating. Advisory in Comment 4.
CC: (none) => andrewsfarm, sysadmin-bugsWhiteboard: (none) => MGA8-64-OKKeywords: (none) => validated_update
Keywords: (none) => advisoryCC: (none) => davidwhodgins
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2022-0052.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
(In reply to Thomas Andrews from comment #8) Would be fun if the solution did need to be "install the version for the arch that almost everyone try to kill" ;) Thanks for the extra information
(In reply to Thomas Andrews from comment #8) > My first attempt to reproduce the situation from Comment 0 was in a > VirtualBox guest. I did not see the issue there. A bit of investigation > revealed that BOTH the 64-bit and 32-bit versions of libzlib1 were > installed, I have no idea when this happened - possibly at installation. > Using the netinstall iso to do the install, it is more than possible that I > activated the 32-bit repos as well as the 64-bit ones. > > Switching to real hardware that didn't have the 32-bit version installed, I > reproduced the fault. It would seem that another workaround for the original > situation could have been to install the 32-bit version of libzlib1. > > I updated using qarepo, with no installation issues. After the update, the > problem from Comment 0 disappeared. In addition, as in Bug 30204, I ran Ark > and Handbrake with no issues. > > I don't know what, if anything, needs to be done about the difference > between the 32-bit and 64-bit versions, but that is something to be > addressed in a different bug. Giving this an OK, and validating. Advisory in > Comment 4. I downgrade to 1.2.12 and make the test , did not works for me, may be you also have the 32bit java also? BTW i updated again to 1.2.12.1 Thanks a lot for the quickly response
The problem didn't show up in a VM but did with real hardware. That may be all there is to it. While VirtualBox is very good, it isn't perfect. I have seen at least two other situations in the last few months where a package works in a Vbox VM, but doesn't work with the host on the same hardware.