JDK-8196968 : One time crash on exit in JNIEnv_::CallObjectMethod
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8,openjfx11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-02-07
  • Updated: 2020-01-31
  • Resolved: 2018-07-27
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 8 Other
8u202Fixed openjfx11Fixed
Related Reports
Relates :  
I only saw this one time while running:

java hello.HelloWebView https://www.bankofamerica.com/

I made the screen larger, clcked around a bit, then closed the window. The crash happened at that point. The hs_err file is attached.

Changeset: 987a6417e320 Author: arajkumar Date: 2018-07-27 10:07 +0530 URL: http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/987a6417e320 8196968: One time crash on exit in JNIEnv_::CallObjectMethod Reviewed-by: mbilla, kcr



ok ..so nullptr initiazation looks redundant in HistoryItem.h (may be we can address this as part of new issue) #if PLATFORM(JAVA) JGObject m_hostObject { nullptr }; #endif

[~mbilla]. JGObject is not a POD type. It is a class and default value is initialised through the constructor. Refer JavaRef.h JGlobalRef.

Changes looks fine (not intrusive ).. Minor query : Since now you are comparing m_nativeDecoder for null, is it a good idea to initialize m_nativeDecoder to nullptr in ImageDecoderJava.h (similar to HistoryItem.h)? JGObject m_nativeDecoder { nullptr };

webrev: http://cr.openjdk.java.net/~arajkumar/8196968/webrev Root cause: From the crash log, I could see that WebCore image decoder is trying to call the Java method(through JNI) after detaching from main thread. This leads to null JNIEnv pointer, which causes the crash. Proposed Solution: Add a null check before accessing the JNIEnv pointer. (Note: I couldn���t reproduce the crash in my dev machine)

I think adding null checks as you suggest seems good, at least for any method that can be called from a destructor.

By enforcing 'nullptr' to 'env' pointer, I got the below crash log which matches exactly with [~kcr]'s crash log. # SIGSEGV (0xb) at pc=0x000000013b426be9, pid=62085, tid=775 # # JRE version: Java(TM) SE Runtime Environment (10.0.1+4) (build 10.0.1+4) # Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0.1+4, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64) # Problematic frame: # C [libjfxwebkit.dylib+0xabbbe9] JNIEnv_::CallObjectMethod(_jobject*, _jmethodID*, ...)+0x79 Also from the attached crash log, I could see the 'THREAD' section shows the current thread as 'native thread' instead of it's actual name. It means that the main thread(aka "JavaFX Application Thread" ) is detached from JVM. --------------- T H R E A D --------------- Current thread is native thread .... I think it is better to do a null check before accessing 'env' in all the places. [~kcr], What is your opinion?

>> # SIGSEGV (0xb) at pc=0x000000013f212b99, pid=68788, tid=775 Access at address `0xb` seems to be a null pointer access from native side, probably 'env' may have become null while closing the window? I see a null check for 'env' pointer in RenderQueue, void RenderingQueue::disposeGraphics() { JNIEnv* env = WebCore_GetJavaEnv(); // The method is called from the dtor which potentially can be called after VM detach. // So the check for nullptr. if (!env) return; But the exception which I posted earlier seems to be a different issue.

Interesting observation. Not sure whether it is related to the crash or not...

Though I couldn't see crash during my testing, I got the below exception. Exception in thread "Thread-19" java.lang.IllegalStateException: Service must only be used from the FX Application Thread at javafx.graphics/javafx.concurrent.Service.checkThread(Service.java:906) at javafx.graphics/javafx.concurrent.Service.isRunning(Service.java:224) at javafx.web/com.sun.javafx.webkit.prism.WCImageDecoderImpl.startLoader(WCImageDecoderImpl.java:144) at javafx.web/com.sun.javafx.webkit.prism.WCImageDecoderImpl.getImageFrame(WCImageDecoderImpl.java:329) at javafx.web/com.sun.javafx.webkit.prism.WCImageDecoderImpl.getFrame(WCImageDecoderImpl.java:272) Looks like something wrong when our image decoders are called from WebKit's threaded image decoding.

This is quite possibly unrelated, but I was running with a build that includes the fix for JDK-8196677