JDK-4240589 : (ref) runFinalizersOnExit(true) causes VM crash for user native libraries
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.2.0,5.0,8,9
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 1999-05-24
  • Updated: 2024-10-09
  • Resolved: 2018-03-20
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.
JDK 11
11Resolved
Related Reports
Duplicate :  
JDK-4238486 - finalize() calling native function results in JVM crash
Relates :  
JDK-4127306 - System.exit does not exit when runFinalizersOnExit(true)
Relates :  
JDK-8183526 - Refactor java/lang/System/finalization/FinExit.sh to java
Relates :  
JDK-8198249 - Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit
Relates :  
JDK-5086661 - JDK 1.5's temporary native libraries may not be deleted on VM exit
Description
This is a more general description of the bug reported in 4119554.

If an application loads a native library and sets the
runFinalizersOnExit flag to true, the VM will crash
on exit if there are any objects that have a finalizer
and the finalizer needs to call a native function in
the library.

The reason is apparently that the
finalizer for the native library classloader unloads the users DLL
before the object finalizer gets called. When the object finalizer
is called there is no DLL and hence the crash.

Test case is attached.
Comments
Close as a dup of JDK-8198249 that has removed System::runFinalizersOnExit in 11.
20-03-2018
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-January/031041.html Below summarizes the analysis of 345587 maven central artifacts. The class/method that calls System.runFinalizersOnExit : 1 com/ibm/as400/access/ProxyServer#main 11 edu/stanford/nlp/parser/lexparser/ChineseSimWordAvgDepGrammar#<clinit> 3 net/handle/server/Main#initialize 29 org/hsqldb/lib/java/JavaSystem#runFinalizers 1 org/objectweb/util/explorer/parser/lib/ZipManager#<init> The number indicates the number of JAR files (maybe same or different artifact ID) contained that class calling System.runFinalizersOnExit. In most cases, a new version of the maven artifact no longer calls System.runFinalizersOnExit method. For HyperSQL case, some maven artifacts included an old version of HyperSQL library will need to be updated with a newer version. It is believed that the number of libraries being impacted is small. org/hsqldb/lib/java/JavaSystem#runFinalizers - a new version of this class (see org.hsqldb:hsqldb:2.4.0) no longer calls it. HyperSQL library is repackaged in several artifacts. Looks like org.ow2.easybeans group such as easybeans-uberjar-openjpa, easybeans-component-hsqldb, easybeans-uberjar-eclipselink needs to be updated with a new version that does not call runFinalizersOnExit. org.apache.hama:hama-examples - a new version does not call runFinalizersOnExit org.apache.servicemix.bundles:org.apache.servicemix.bundles.hsqldb:1.8.0_7_2 does not call it. But 1.8.0_10_2 calls runFinalizersOnExit method while 1.8.0_7_2 and 1.8.0_10_2 are published on the same date. org.apache.openejb:openejb-lite:4.7.5 does not call it com/ibm/as400/access/ProxyServer#main ([Ljava/lang/String;)V - Newer versions of this artifact no longer calls it. edu/stanford/nlp/parser/lexparser/ChineseSimWordAvgDepGrammar#<clinit> ()V - a newer version 3.8.0 does not call System.runFinalizersOnExit net/handle/server/Main#initialize ()V from org/dspace/handle/6.2/handle-6.2.jar - this artifact has not been updated since 2008 org/hsqldb/lib/java/JavaSystem#runFinalizers ()V - this class is included in from org/apache/hama/hama-examples/0.3.0-incubating/hama-examples-0.3.0-incubating.jar - Newer versions of hama-examples no longer calls it. org/objectweb/util/explorer/parser/lib/ZipManager#<init> ()V - the artifact org.objectweb.util.explorer:explorer is not updated since the first release in 2006
01-02-2018
When these methods are removed, the corresponding tests from the regression suite should also be removed. One such test is: jdk/test/java/lang/System/finalization/FinExit.sh
27-07-2017
Deprecation of these methods is covered by JDK-8153330.
02-04-2016
With enhanced deprecation (JEP 277), Runtime.runFinalizersOnExit() and System.runFinalizersOnExit() will be marked for removal. They have been deprecated since 1998 and will be removed in JDK 10.
02-04-2016
Investigation on JDK-4238486 has shown that replacing the ClassLoader's finalizer with phantom reference has complicated issues such as JNI FindClass and security impact to be resolved. System.runFinalizationOnExit() is inherently unsafe and has been deprecated since 1998 (JDK 1.2). I propose to make an incompatible change in JDK 9 and change this method to throw UnsupportedOperationException.
10-01-2015
Log for JDK9/JCK9: http://scaaa008.us.oracle.com:9502/runs%2F506338.ManualSubmit-1/vm/concepts/execution/execution062/execution06204m1/execution06204m1.jtr
12-06-2014
Added 'tck-red-9' label to identify this as a tck-red issue for JDK 9, based on conformance bug tagging process: http://wiki.se.oracle.com/display/JPG/Tagging+and+Prioritizing+Conformance+Bugs
11-04-2014
The native library is currently unloaded when a ClassLoader's finalizer is invoked. PhantomReference can resolve this VM crash problem as the ClassLoader no longer has a finalizer be invoked on exit. On the other hand, there is still no guarantee when the native library will be unloaded after the ClassLoader is GC'ed. JNI FindClass relies on the ClassLoader NativeLibrary implementation to find the caller's class and its class loader if JNI FindClass is called when the native library is being loaded and unloaded (i.e. JNI_OnLoad and JNI_OnUnload is being called). However, when the ClassLoader is GC'ed, that means the caller's class that loads the native library is being GC'ed. The PhantomReference solution would resurrect the caller's class if it has to support the current FindClass dependency. The JNI spec about JNI_OnUnload states the following: The VM calls JNI_OnUnload when the class loader containing the native library is garbage collected. This function can be used to perform cleanup operations. Because this function is called in an unknown context (such as from a finalizer), the programmer should be conservative on using Java VM services, and refrain from arbitrary Java call-backs. I think JNI FindClass should not be called during JNI_OnUnload but the compatibility risk may not be small (there are tests doing that).
19-03-2014
Release team: Approved for deferral. Please evaluate if this should really be fixed instead of closing as WNF as it's been there for 14 years without fixing.
14-01-2014
SQE is OK for defer.
13-01-2014
for aurora linkage: RULE vm/concepts/execution/execution062/execution06204m1/execution06204m1 any any RULE vm/concepts/execution/execution062/execution06204m1/execution06204m1 Crash any
20-05-2013
reproducible on embedded java8 b44e-pit on all non-x86 platforms
13-02-2013
WORK AROUND 1. Don't call runFinalizersOnExit() or 2. Put the user DLL in the bootclasspath, so it doesn't get unloaded.
11-06-2004
EVALUATION Rather than using a finalizer in ClassLoader$NativeLibrary, phantom references should be used. See also bug 4240589. ###@###.### 2002-07-16 Oops, typo -- I meant see also bug 4238486 above. It's probably a duplicate. ###@###.### 2002-07-16
16-07-2002
SUGGESTED FIX Maybe, Finalizer.runFinalizersOnExit() should not finalize ClassLoader instances until all other objects have been finalized. Would require two passes through the list but would be easy otherwise. ###@###.### 2002-03-15 mr@sfbay suggested using phantom references, but I don't understand how. --------------- I have an email exchange on this bug, but here's the summary: Fred said: >> The only problem here is that the VM/Lang specs do not specify when a >> native library gets unloaded (if ever). The fact that we chose to >> unload a library in a finalizer causing subsequent native finalizers to >> fail is an implementation problem that must be fixed. > Mark replied: >Agreed. This is what phantom refs are for. Please get in touch with ###@###.### if you'd like the complete email exchange (there are several messages and some background as we figured out whether the problem was in finalizers themselves or in the use of finalizers by ClassLoaders). ###@###.### 2002-07-16
16-07-2002