JDK-4731870 : ZipFile causes an exception in native code without informing user of which file.
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 1.4.1,1.4.2
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: solaris_8,windows_2000
  • CPU: x86,sparc
  • Submitted: 2002-08-15
  • Updated: 2006-09-19
  • Resolved: 2006-09-19
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
Name: gm110360			Date: 08/14/2002


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

Windows 2000, Service Pack 3.

A DESCRIPTION OF THE PROBLEM :
This has happened since 1.3 and I've filed a bug; the
response was to upgrade to 1.4 and I have.  A project I'm
working on has several JAR files - one is corrupt and
causing the ZipFile class to bomb in native code, but the
output does not specify which file caused the error.  It
really, really should.

This occurs every single time I attempt to compile the said
project.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Add a JAR file with a corrupt byte to the classpath.
2. Compile a program.
3. Watch the explosion.

EXPECTED VERSUS ACTUAL BEHAVIOR :
You would expect the name of the corrupt file to appear in
the output - it doesn't.

ERROR MESSAGES/STACK TRACES THAT OCCUR :

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x6D32797D
Function=ZIP_Open+0x369
Library=C:\jdk1.4\jre\bin\zip.dll

Current Java thread:
	at java.util.zip.ZipFile.getNextEntry(Native Method)
	at java.util.zip.ZipFile.access$400(ZipFile.java:26)
	at java.util.zip.ZipFile$2.nextElement(ZipFile.java:301)
	at com.sun.tools.javac.v8.code.ClassReader.openArchive(ClassReader.java:975)
	at com.sun.tools.javac.v8.code.ClassReader.list(ClassReader.java:1202)
	at com.sun.tools.javac.v8.code.ClassReader.listAll(ClassReader.java:1323)
	at com.sun.tools.javac.v8.code.ClassReader.fillIn(ClassReader.java:1345)
	at com.sun.tools.javac.v8.code.ClassReader.complete(ClassReader.java:1052)
	at com.sun.tools.javac.v8.code.Symbol.complete(Symbol.java:335)
	at com.sun.tools.javac.v8.comp.Enter.visitTopLevel(Enter.java:470)
	at com.sun.tools.javac.v8.tree.Tree$TopLevel.accept(Tree.java:393)
	at com.sun.tools.javac.v8.comp.Enter.classEnter(Enter.java:445)
	at com.sun.tools.javac.v8.comp.Enter.classEnter(Enter.java:459)
	at com.sun.tools.javac.v8.comp.Enter.complete(Enter.java:591)
	at com.sun.tools.javac.v8.comp.Enter.main(Enter.java:577)
	at com.sun.tools.javac.v8.JavaCompiler.compile(JavaCompiler.java:337)
	at com.sun.tools.javac.v8.Main.compile(Main.java:523)
	at com.sun.tools.javac.Main.compile(Main.java:39)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at org.apache.tools.ant.taskdefs.compilers.Javac13.execute(Javac13.java:92)
	at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:530)
	at org.apache.tools.ant.Task.perform(Task.java:217)
	at org.apache.tools.ant.Target.execute(Target.java:164)
	at org.apache.tools.ant.Target.performTasks(Target.java:182)
	at org.apache.tools.ant.Project.executeTarget(Project.java:601)
	at org.apache.tools.ant.Project.executeTargets(Project.java:560)
	at org.apache.tools.ant.Main.runBuild(Main.java:454)
	at org.apache.tools.ant.Main.start(Main.java:153)
	at org.apache.tools.ant.Main.main(Main.java:176)

Dynamic libraries:
0x00400000 - 0x00406000 	C:\jdk1.4\bin\java.exe
0x77F80000 - 0x77FFB000 	C:\WINNT\System32\ntdll.dll
0x77DB0000 - 0x77E0D000 	C:\WINNT\system32\ADVAPI32.dll
0x77E80000 - 0x77F36000 	C:\WINNT\system32\KERNEL32.DLL
0x77D30000 - 0x77DA1000 	C:\WINNT\system32\RPCRT4.DLL
0x78000000 - 0x78046000 	C:\WINNT\system32\MSVCRT.dll
0x6D330000 - 0x6D45C000 	C:\jdk1.4\jre\bin\client\jvm.dll
0x77E10000 - 0x77E75000 	C:\WINNT\system32\USER32.dll
0x77F40000 - 0x77F7C000 	C:\WINNT\system32\GDI32.DLL
0x75E60000 - 0x75E7A000 	C:\WINNT\System32\IMM32.DLL
0x6D1D0000 - 0x6D1D7000 	C:\jdk1.4\jre\bin\hpi.dll
0x6D300000 - 0x6D30D000 	C:\jdk1.4\jre\bin\verify.dll
0x6D210000 - 0x6D229000 	C:\jdk1.4\jre\bin\java.dll
0x6D320000 - 0x6D32D000 	C:\jdk1.4\jre\bin\zip.dll
0x77920000 - 0x77943000 	C:\WINNT\system32\imagehlp.dll
0x72A00000 - 0x72A2D000 	C:\WINNT\system32\DBGHELP.dll
0x690A0000 - 0x690AB000 	C:\WINNT\System32\PSAPI.DLL

Local Time = Mon Aug 12 11:07:10 2002
Elapsed Time = 17
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.1-beta-b14 mixed mode)
#


REPRODUCIBILITY :
This bug can be reproduced always.


(Review ID: 160663) 
======================================================================

Comments
EVALUATION The crux of the request is that the name of a zip file should be given when that zip file causes a JVM crash. But as previously posted, the crash shouldn't happen any more due to fixes in 1.3.1_11 and 1.4.2 (see bug 4766057). Indeed, all the comments on this bug are related to releases prior to those two, and the comments are somewhat old (the most recent on 21/Apr/2003, against 1.4.1_02). Furthermore, discussion with JVM engineering indicates that getting the name of the offending file isn't even possible: Once the JVM is crashing, it has no knowledge of the file name, and no way to transfer control to any code that might know the file name. For those reasons, I'm closing this RFE.
19-09-2006

EVALUATION The underlying cause of the crash was fixed in 1.3.1_11 and 1.4.2 via change for 4766057.
15-09-2006

EVALUATION This looks like it might be an RFE. -- iag@sfbay 2002-8-14
14-08-2002