JDK-8160704 : JVM crash once unloading libraries
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7u25
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2016-06-14
  • Updated: 2025-05-21
  • Resolved: 2016-07-11
Related Reports
Relates :  
JDK-8164512 - Replace ClassLoader use of finalizer with phantom reference to unload native library
Description
 FULL PRODUCT VERSION :
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
CentOS release 5.2 (Final)

A DESCRIPTION OF THE PROBLEM :
I  use apache-tomcat-7.0.52 container to run run my application (.war file) which uses c++ native libraries. I should be able to upgrade my war file without shutting down tomcat (which may run multiple such applications). Each time my war file is copied to the apache-tomcat-7.0.52/webapps folder it loads new version of my c++ dll, thus to be able to load new version of this dll I have to unload old library from java.exe first. To make old library unload work properly I  have to use Custom Class loader so that it gets garbage collected when one removes .war file from webapps. When class loader is garbage collected by dll gets unloaded from java.exe and I can load new dll to the process during upgrade of war file.  The problem is that I see sporadic crashes during this unloading process. My investigation shows that problem rises when JNI_OnUnload gets called before Java_com_sun_jna_Native_close is called. If JNI_OnUnload is called before Java_com_sun_jna_Native_close, program tries to find Java_com_sun_jna_Native_close symbol using an invalid handle (as JNI_OnUnload has already been called). Thus dlsym crashes the application. 


REPRODUCIBILITY :
This bug can be reproduced occasionally.
Comments
The error situation has been removed with JDK-8164512.
21-05-2025
Closing as duplicate of JDK-8160567
11-07-2016
True, but the JDK has the same basic problem - see JDK-8160567 and related issues. Unloading via a ClassLoader finalizer() is unsafe.
01-07-2016
During Finalizer Crash occured outside the java vertual machine in native code This is not java issue, error logs tells the story == v ~StubRoutines::call_stub j com.sun.jna.Native.close(J)V+0 j com.sun.jna.NativeLibrary.dispose()V+85 j com.sun.jna.NativeLibrary.finalize()V+1 v ~StubRoutines::call_stub This is the "Java Native Access" library: https://java.net/projects/jna Not a JDK issue. Hence closing not an issue
01-07-2016
Subsequent comment from the submitter with the workaround to resolve the issue: ---------------------------------------------------- We have implemented a workaround to fix the problem. We have implemented our own standalone library(without dependencies) to provide stuff we need from libc and msvcrt to load it as jomd.dll gets loaded(by setting correct "java.library.path" programatically) and use jni to call methods of this dll. This way we eliminate the need to call Native.loadLibrary((Platform.isWindows() ? "msvcrt" : "c") from war file source code and tmp dll does not get created in temp directory of tomcat. Thus issue with the order of calls JNI_OnUnload and Java_com_sun_jna_Native_close should gone away for us. We just want to describe the problem for you so that you can apply a fix into the next java versions. -------------------------------------------------
29-06-2016
Sent an email to the submitter requesting a test case to reproduce this issue.
28-06-2016