JDK-4425695 : Updating jar files crashes running programs
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version:
    solaris,javadb_10.0,2.0,1.3.0,1.4.1,1.4.1_01,5.0,5.0u1,6,6u16 solaris,javadb_10.0,2.0,1.3.0,1.4.1,1.4.1_01,5.0,5.0u1,6,6u16
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS:
    generic,linux,linux_redhat_9.0,solaris,solaris_9,solaris_nevada,solaris_10,windows_2000 generic,linux,linux_redhat_9.0,solaris,solaris_9,solaris_nevada,solaris_10,windows_2000
  • CPU: generic,x86,sparc
  • Submitted: 2001-03-14
  • Updated: 2012-10-10
Related Reports
Duplicate :  
JDK-6713913 - Fatal errors during jar file processing
Duplicate :  
JDK-5082306 - SIGBUS from libzip.so in Tiger b60
Duplicate :  
JDK-6236070 - Unexpected eeror in HotSpot VM. It got a SIGBUS.
Duplicate :  
JDK-6578394 - javaws-started app dumps core in libzip`ZIP_GetEntry
Duplicate :  
JDK-6553958 - JVM crash when running NetBeans 6.0
Duplicate :  
JDK-4843994 - JarURLConnection gets confused and throws exceptions after replacing jar file
Duplicate :  
JDK-6179434 - SIGBUS from ZipFile.getEntry
Duplicate :  
JDK-6426429 - crash when browsing to webapp/portlet URL while JAR file is being updated/reloaded
Duplicate :  
JDK-7129299 - JVM crash issue related to jar files
Relates :  
JDK-5086611 - Reading of JarEntry results in Hotspot error instead of throwing Java Exception
Relates :  
JDK-6390352 - SIGBUS in libzip.so when using java.util.zip
Relates :  
JDK-6633178 - JVM crash (SIGBUS) on T2000
Relates :  
JDK-6795309 - JVM crashes after ^C when .jar file updated while application is running
Description
Name: boT120536			Date: 03/14/2001


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)

Occasionnally, when updating a jar file while a java program uses it, said jave program throws
spurious ClassNotFound errors. This is somewhat surprising, as similar problems don't occur
when for instance updating a shared library (.so file) while programs use it.

The problem occurs both on Windows and on Linux

The reason why it doesn't happen for C libraries is because these are mmapped in PRIVATE
mode into the program's address space, and hence the program sees a snapshot of their state how
the library was when first started. It can thus continue its work undisturbed even through updates.

Would it be possible to implement a similar scheme for access to .jar? For platforms where mmap
is not supported, such as Windows, the jar could be read entirely in memory upon first use.
(Review ID: 118787) 
======================================================================
Comments
EVALUATION > should this bug be 1. closed as fixed The fix for #6929479 (system property to avoid mmap) offers a workaround for users affected by the problem. I don't know if that counts as a full fix but it may be the best that can be done with available engineering. > 2. transferred to the jdk Probably yes - it is not a HotSpot issue that I can see. (The VM of course reads ZIP files such as rt.jar for the bootstrap loader, but these are not "userland" JARs and there is no expectation of robustness if they are tampered with.)
21-09-2010
EVALUATION This is not so much an RFE as a potentially serious reliability bug in the JRE: accidental use of ZipFile on the wrong file crashes the entire VM rather than throwing a polite IOException. For certain classes of program, such as development tools, it is pretty normal to be recreating JARs, and it is hard to be sure that nothing in the VM is holding a ZipFile open on a given file. (The new URLClassLoader.close is nice, but only helps if you know and control all the places where a URLClassLoader might have been created to begin with.) Furthermore, the crash is avoidable by using libzip only for the bootstrap loader in native code, whose scope of behavior is quite limited; and rewriting ZipFile in pure Java code, likely using NIO. The new code could be written to offer various levels of robustness against dynamic changes in the file, but at worst you would get an ArrayIndexOutOfBoundsException or the like. There are already several such nonnative implementations in the wild (e.g. in Apache Ant) so it cannot be that hard. I have mentioned this in the past to some people working on Java with a positive reception, but to my knowledge this BugTraq item is the only place where the possibility was held open.
20-09-2010
EVALUATION We will not address this RFE. See other comments.
01-09-2010
EVALUATION Since JDK 6 build 45, the mmap behavior is completely gone on Linux & Solaris. We are reading jar files uniformly on all platforms. The motivation of that shift is to reduce the perceived memory footprint.
13-06-2007
EVALUATION fred.oliver@East 2001-06-27 Reading in an entire jar file is not acceptable, as it increases the memory requirements of a running java application, possibly tremendously. Reducing memory footprint is a very significant priority for us. Changing the jar file while Java is using it is not supported, any more than modifying classes in a class path directory on the fly. Consequently, this RFE should not be addressed on those grounds. Current versions of Java for Solaris do mmap jar files. It is reasonable to extend this functionality to Linux and Win32 because mapping files for other memory sharing activities is being investigated. I will leave this bug open until this is further investigated.
20-09-2004
WORK AROUND Name: boT120536 Date: 03/14/2001 Restart the applications for all updates to .jar files, even if the particular update doesn't touch any class actually used by the application. ======================================================================
20-09-2004