JDK-6501408 : URLClassLoader loads resources from incorrect / out-of-date jar and suspected corruption/sigsegv
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 5.0u8
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2006-12-06
  • Updated: 2017-07-20
  • Resolved: 2017-07-20
Related Reports
Relates :  
JDK-6487095 - URLClassLoader fails to reload resources from dynamically changed jar-files
Relates :  
JDK-4167874 - URL-downloaded jar files can consume all available file descriptors
Description
URLClassLoader getResourceAsStream reads from wrong/old Jar file and believed to cause corruption of the resource stream and/or sigsegv of JVM

This can cause correct code to generate incorrect results and/or sigsegv.

Symptoms:

A module of code is dynamically loaded into a JVM using a URLClassLoader, the module code and resources (property files) are in a jarfile on the URLClassLoader's path.

The dynamically loaded module reads resources (property files) through its classloader. It gets the expected resource streams.

The module is unloaded from the JVM, the classloader is garbage collected sucessfully.

The module's jar file is updated to a new version of the module and new version of the property files.

The module is re-loaded into the JVM with a new classloader, using the updated jar file in the same filesystem location.

The module is re-executed. The new code is executed, but classloader.getResourceAsStream() returns the contents of the property file from the OLD jar file which no longer exists on the filesystem.

... we believe that the jar file has been cached in the JVM and the old jarfile is being reused by mistake in getResourceAsStream

** ISOLATED CODE TO REPRODUCE BUG ***

Attached to this bugid is a standalone program demonstrating the problem in a simple use-case, it creates multiple jars with just 1 resource in and then shows, when renaming the jars, how the old version of the jar is being used at the wrong time.

** Old resources, but new code **

It would appear in our test cases that if we execute code from this URLClassLoader through reflection, the *new* code executes, but the *old* resource streams are found by this new code.

** Data Corruption and SIGSEGV **

We have seen, in more complex use-cases, corruption of the values of the properties being returned, and have seen a sigsegv from Java 6 beta 2 we believe is due to this problem, the stack being attached too.


Conclusion

This bug prevents clean upgrade of java modules loaded into containers, they execute in a corrupted context and produce unexpected behavior. For example, if the port number used to offer a service comes from a property file, an old (incorrect) port number would be used.

Reproduced on:

solaris/sparc
linux/i386

with Java 6, Java 5, Java 1.4, Java 1.3


We believe, by reading 6349735, that it would not be possible to replace the jarfile
on windows. We can replace it on solaris and linux.
Comments
Java SE 9 has added setDefaultUseCaches(String protocol, boolean defaultVal) to control caching at the per-protocol level.
20-07-2017
EVALUATION This is caused by the caching of jar files loaded. see workaround section to show how to disable this caching.
06-03-2007
WORK AROUND Turn off caching. For example: URL url = new URL("http://www.sun.com/"); URLConnection uc = url.openConnection(); uc.setDefaultUseCaches(false); One negative side effect is that caching for all protocols will be disabled.
06-03-2007
SUGGESTED FIX Workaround is believed to be to change URL behavior overriding URL.openConnection() to prevent caching of the URLConnection when creating classloader... needs verification. [ Nick ]
06-12-2006