Bug ID: JDK-4991229 REGRESSION: Invalid or corrupt jarfile with 1.5Beta

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
5.0 b42Fixed


Name: gm110360			Date: 02/09/2004


FULL PRODUCT VERSION :
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b32c)
Java HotSpot(TM) Client VM (build 1.5.0-beta-b32c, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Windows 98 [Version 4.10.1998]


A DESCRIPTION OF THE PROBLEM :
The application I created and ran fine with Java 1.4.2_01-b06 now returns Invalid or corrupt jarfile with 1.5Beta.

I tracked what the problem was and it seems to be the open source obfuscator Retroguard. Note that other software obfuscated with Retroguard works ok with 1.5Beta.

The particulary of my file was that it used
.attribute SourceFile to preserve the source file attribute
.attribute LineNumberTable to preserve the line number table

I submitted this bug hoping you would be interested to know and that using your bedug tools you could point to what went wrong. If not you can close this bug.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Download http://www.antcommander.com/AntCommander-pb.zip
unzip it and execute java -jar AntCommander.jar

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
A nice GUI ;-)
ACTUAL -
D:\Lg\AntCommander\0.7\test2>java -jar AntCommander.jar
Invalid or corrupt jarfile AntCommander.jar


ERROR MESSAGES/STACK TRACES THAT OCCUR :
Invalid or corrupt jarfile AntCommander.jar

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Don't obfuscate or use java 1.4.2

Release Regression From : 1.4.2_03
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Incident Review ID: 237682) 
======================================================================

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b42 tiger-beta2

14-06-2004

SUGGESTED FIX 14: sccs diffs parse_manifest.c ------- parse_manifest.c ------- 245c245,247 < * actual size of the header can't be determined. --- > * actual size of the header can't be determined. The addition of > * SIGSIZ guarantees that the next signature is also in the buffer > * for proper loop termination. 248c250 < bytes < CENHDR + CENNAM(p) + CENEXT(p) + CENCOM(p)) { --- > bytes < CENHDR + CENNAM(p) + CENEXT(p) + CENCOM(p) + SIGSIZ) { 264a267,269 > * > * The allocation of SIGSIZ additional bytes guarantees that the > * next signature is also in the buffer for proper loop termination. 267c272 < if (entry_size > bufsize) { --- > if (entry_size + SIGSIZ > bufsize) {

11-06-2004

EVALUATION Looks suspiciously like 4956055 executing jar reports "Invalid or corrupt jarfile..." on previously working jar that should have been fixed before the release of Tiger beta. Transferring bug to jek3, the author of the code in question (part of the launcher). ###@###.### 2004-02-14 The problem is that in the buffer allocation scheme for reading the central directory of the jar/zip file, great pains are taken to ensure that entire records are available. Unfortunately, this isn't enough, because to logic depends upon the first 4 bytes of the next record (the record signature) are also available for proper loop termination. ###@###.### 2004-02-17

17-02-2004