JDK-8196011 : Intermittent crash when using WebView from JFXPanel application
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8u161,10
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • CPU: generic
  • Submitted: 2018-01-22
  • Updated: 2023-12-22
  • Resolved: 2018-02-23
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 10 JDK 8 Other
10.0.2Fixed 8u172Fixed jfx11Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)

and

java version "1.8.0_162"
Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 10.0.15063]

A DESCRIPTION OF THE PROBLEM :
The JavaFX WebView is very unstable since the latest JRE updates. It's very annoying that the crashes can be reproduced at both java version 8u161 and 8u162. 

I thought the idea behind the different versions was that the odd version gets important security fixes and the even version gets a patch-set update....

Our Swing application opens a WebView in a separat JFrame by using the JFXPane. We noticed that the applicatoin crashes if a user switches to another application e.g. Outlook and than back to the WebView by clicking e.g. on a HTML TextField.

The mentioend java frames at the hs_log_pid log files were different at the most crashes:


We tried to write a test program which reproduces the same JVM crash but the crashes were very random.

But in the end we found another way to crash the WebView -> just open http://www.wikipedia.org


REGRESSION.  Last worked in version 8u152

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Just open http://www.wikipedia.org


ERROR MESSAGES/STACK TRACES THAT OCCUR :
A number of crash files are available at:
https://drive.google.com/open?id=1c-d8spA2Q9GCll9KX9ErREU4Nck1VB5L

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package jfxtest;

import javax.swing.JButton;
import javax.swing.JFrame;

import javafx.application.Platform;
import javafx.embed.swing.JFXPanel;
import javafx.scene.Scene;
import javafx.scene.web.WebView;


public class JFXTest
{
	public static void main(String[] args)
	{
		Platform.setImplicitExit(false);
		
		JFrame frame = new JFrame("JFXTest");
		frame.setSize(800, 600);
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		
		JButton openNewFrameButton = new JButton("Open a new JFrame");
		openNewFrameButton.addActionListener(l ->
		{
			JFrame newFrame = new JFrame("New Frame");
			JFXPanel jfxPanel = new JFXPanel();
			
			Platform.runLater(() ->
			{
				WebView webView = new WebView();
				webView.getEngine().load("http://www.wikipedia.org");
				
				Scene scene = new Scene(webView);
				jfxPanel.setScene(scene);
			});
			
			
			newFrame.add(jfxPanel);
			newFrame.setSize(800, 600);
			newFrame.setVisible(true);
			newFrame.toFront();
			
		});
		
		frame.add(openNewFrameButton);
		frame.setVisible(true);
	}
}

---------- END SOURCE ----------


Comments
Changeset: 808d535c4e15 Author: ghb Date: 2018-02-23 09:21 +0530 URL: http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/808d535c4e15
23-02-2018

I am satisfied with the explanation of why the fix won't lead to deadlock. Note that the methods in question are intended for use by IME code, which can be called on the AWT EDT in the case of a JFXPanel application. The fix looks correct to me, and my testing shows no problems. +1 for webrev.04
22-02-2018

Changing the affected version back to 8u161. We don't have a case that shows the failure with an earlier version. I believe that this bug was likely exposed by the fix for JDK-8184016. That bug fix causes the AWT IME code to request the text location from a hit test in more cases than previously done. The fix for JDK-8184016 was integrated into JDK 10 build 23 and also backported to JDK 8u161, which is consistent with the results of testing. Technically this is not a regression, but a latent bug that was exposed by a change in the JDK, but the effect on applications is the same as if it were a regression, so we should treat it as such (thus leaving the regression keyword).
22-02-2018

+1 for webrev.04.
22-02-2018

With my previous comment. This solution will block the event thread for 'getText' and 'getPos' which intern causes the 'FrameView::layout ' (native of WebView). These two API don't have any call back (Had debug prints + Loggers log with FINE didn't show any call back from native to Java objects / Context) which might lead to dead lock.
21-02-2018

Have you done the analysis to see whether deadlock is possible?
21-02-2018

updated Webrev : http://cr.openjdk.java.net/~ghb/8196011/webrev.04/ 1. WebPage::setSize // let me call setSize Java_com_sun_webkit_WebPage_twkSetBounds FrameView::resize FrameView::setFrameRect FrameView::scheduleRelayout async update layout //FrameView::layout 2. Java_com_sun_webkit_WebPage_twkGetTextLocation // let me call getText FrameView::FrameSelection::absoluteCaretBounds FrameSelection::updateSelectionByUpdatingLayoutOrStyle (static) FrameView::layout 3. Java_com_sun_webkit_WebPage_twkGetInsertPositionOffset // let me call getPos FrameView::FrameSelection::absoluteCaretBounds FrameView::VisibleSelection::visibleStart FrameView::VisiblePosition::canonicalPosition Document::updateLayoutIgnorePendingStylesheets Document::updateLayout() FrameView::layout Race condition occurs if two thread starts executing 'setSize' and 'getText / getPos'. Execution of 'getText' / 'getPos' will take more time (In Worst case scenario) than 'setSize' and they (getText & getPos) Don't call back Java context which leads to recursive call. Testing : a. programmatically i have added a debug boolean flag being set on Enter and Exit to 'setSize'. Crash used to occur all the time when 'getText' is called during 'setSize' yet to finish its execution. Added Debug prints and executed JFXTest and make sure 'getText' is blocked until 'setSize' is executed. b.Shared the javafx binary with [~pmangal] and got the fix verified.
21-02-2018

This bug is not a regression as was initially reported. Rather it is a race condition caused by calling into native WebKit code via JNI from the wrong thread. I am changing the summary to match the actual problem, which can only happen in the case of SwingInterop. [~ghb] Can you confirm that you have seen this crash on 8u152? If so, please add a comment to this effect.
20-02-2018

>>"So the test can just verify whether it receives the exception incase if it is called from non FX main thread" >>By implementing either FutureTask / invokeOnEventThread we are not throwing exception. Unless i restrict the fix to checking only with 'isEventThread'. As i wrote this Unit test and with fix and without fix it didn't make any sense unless i write the threading events based unit test which will prove the crash (without the fix and with Unit test in place). I meant to check thread fromWebPage.getClientTextLocation method, like below, public int[] getClientTextLocation(int index) { lockPage(); Invoker.getInvoker().checkEventThread(); ... } From unittest, @Test(expected = IllegalStateException.class) void testInputMethodClientFromNonEventThread() { ... // Need not to verify functionality, just check whether it throws exception or not. webPage.getClientTextLocation(0); } webrev.03, add the below statement also into FutureTask, WCPoint point = webPage.getPageClient().windowToScreen(new WCPoint(0, 0));
17-02-2018

Other than my question about the deadlock (and the recommendation about the exception) the fix looks good to me. If you can show that the cases where this is called from the EDT will never hold a lock or resource that will block the FX thread from completing the FutureTask, that should be sufficient. One more minor nit: private final static Logger ... Our code convention is to put static before final, so "private static final Logger ..."
16-02-2018

Here are my comments on the .03 webrev: 1. Please provide an analysis of why this fix cannot lead to deadlock. In general, we need to be very careful when blocking the EDT waiting for FX thread (or vice versa). 2. I do not recommend throwing an AsssertionError on lines 141 and 160. I recommend either throwing a runtime exception or simply returning null / 0 (which is what you do for an InterruptedException). How much testing have you done?
16-02-2018

Updated webrev : http://cr.openjdk.java.net/~ghb/8196011/webrev.03/
16-02-2018

"So the test can just verify whether it receives the exception incase if it is called from non FX main thread" By implementing either FutureTask / invokeOnEventThread we are not throwing exception. Unless i restrict the fix to checking only with 'isEventThread'. As i wrote this Unit test and with fix and without fix it didn't make any sense unless i write the threading events based unit test which will prove the crash (without the fix and with Unit test in place).
16-02-2018

>>1. What's the benefit of using FutureTask compared to what i have used a helper "invokeOnEventThread" ? Just for the sake of readability. Also I could see FutureTask being used across WebCore - JFX interface layer. It is good to maintain the consistent pattern. >>3. Crash occurs with 'WebPage.setSize() and WebPage. getClientTextLocation()) being called concurrently (as mentioned in my previous comment). Do i still need to implement FutureTask / invokeOnEventThread for "InputMethodClientImpl.getLocationOffset" (For which i don't have a steps to reproduce currently) and i am not sure this will lead to crash ? According to the code, looks like all interface method of InputMethodRequest will be called from EDT. It is better to call it's corresponding WebPage methods from JFX Event Thread. >>4. Do suggest what kind of Unit test is expected (Mentioned below) ? According to my understanding, WebCore APIs are not designed to call from multiple threads, so better thrown a exception from WebPage.getClientTextLocation incase it not called from FX main thread. So the test can just verify whether it receives the exception incase if it is called from non FX main thread. Something like MiscellaneousTest.testDOMObjectThreadOwnership (Refer JDK-8133775)
16-02-2018

Thanks [~kcr][~arajkumar], Call to getTextLocation(..) is called from AWT EDT (At the time of crash). 1. What's the benefit of using FutureTask compared to what i have used a helper "invokeOnEventThread" ? 2. Do i need to use FutureTask as suggested or "invokeOnEventThread" will be OK in InputMethodClientImpl.getTextLocation(..) 3. Crash occurs with 'WebPage.setSize() and WebPage. getClientTextLocation()) being called concurrently (as mentioned in my previous comment). Do i still need to implement FutureTask / invokeOnEventThread for "InputMethodClientImpl.getLocationOffset" (For which i don't have a steps to reproduce currently) and i am not sure this will lead to crash ? 4. Do suggest what kind of Unit test is expected (Mentioned below) ? Unit test Case 1 : Just verify the call to 'getClientTextLocation' from non event thread, which is not target to check the actual problem (Crash). Case 2 : verify crash , this is bit fuzzy as of now. a. WebPage which should have decent enough renderable content, which should take enough time be in 'Document::updateLayout' b. Need to have two threads ,one event thread which calls WebPage.setSize() and second one calls WebPage. getClientTextLocation, c. Need to run step a and b multiple times, manually it takes 2 to 10 min.
16-02-2018

> Invoker.getInvoker().invokeOnEventThread(f); > return f.get(); That still blocks the thread waiting for the FX event thread. It might be OK, but you will need to verify that this method cannot be called from the AWT EDT while holding a lock that the FX thread needs (else it will deadlock).
15-02-2018

I was mentioning something similar like below from InputMethodClientImpl.java, getTextLocation, FutureTask<Point2D> f = new FutureTask<Point2D>(() -> { int[] loc = webPage.getClientTextLocation(offset); WCPoint point = webPage.getPageClient().windowToScreen( // We need lower left corner of the char bounds rectangle here new WCPoint(loc[0], loc[1] + loc[3])); return new Point2D(point.getIntX(), point.getIntY()); }); Invoker.getInvoker().invokeOnEventThread(f); return f.get(); then also do a thread check from WebPage.getClientTextLocation, so that you can easily test the same from unit test. You may need to handle the same for getLocationOffset as well. Probably for all overriden methods of InputMethodRequest?
15-02-2018

The only concern with a blocking call is the possibility of deadlock if called from the AWT event thread while it holds a resource that the FX thread needs. Have you confirmed whether or not this can happen?
15-02-2018

updated webrev ; http://cr.openjdk.java.net/~ghb/8196011/webrev.02/
15-02-2018

Will try to write a blocking call to getClientTextLocation and update the webrev. Writing test ? given the steps to reproduce crash and justify the unit test might be complicated. But I will try to see if its possible.
15-02-2018

Instead of returning some default value, I think it is better to invoke the "WebPage.getClientTextLocation" from Event thread using `FutureTask` and `Invoker.invokeOnEventThread`. If possible write a test as well.
15-02-2018

JFXTest : has a JPanel which contains WebView. a. Launch the application (JFXTest) --> Click on "Open New JFrame" --> Opens WebView and loads http://www.wikipedia.com b. While keeping the Jframe in Focused, Do switch to some other application multiple times (Focus gain and Focus lost for WebView windows) c. Navigate some links in "wikipedia" d. Change the size of JPanel (Keeping WebView focused) and repeat (b) --> (c) --> (d) Crash occurance is randome some time we need to do the step (b) to (d) for 2 min some times ~10 min. Root Cause : While debugging WebPage get's two events from Event handler 1. WebPage.setSize(size of window) 2. getTextLocation(index of text) Crash occurs when 1st API is yet to complete the execution, 2nd API is called (From Non Event thread). This leads to race condition where both API tries to relayout the RenderTree and leads to crash. Call stack are random (Top of stack) but the originating sequence are : ... // above this stack are random WebCore::Document::updateLayoutIgnorePendingStylesheets WebCore::FrameSelection::absoluteCaretBounds Java_com_sun_webkit_WebPage_twkGetTextLocation Solution : http://cr.openjdk.java.net/~ghb/8196011/webrev.01/ Don't send textlocation for non EventThread. I can throw an exception with below changes --------------------- @@ -918,6 +918,7 @@ log.log(Level.FINE, "getClientTextLocation() request for a disposed web page."); return new int[] { 0, 0, 0, 0 }; } + Invoker.getInvoker().checkEventThread(); return twkGetTextLocation(getPage(), index); ----------------- Its safe to send default location instead of throwing an exception. Test : Tested on Windows with JFXTest (attached in JBS), Shared the local build to [~pmangal] and we both didn't see any crash after this fix.
14-02-2018

Time to crash depends on timing of (1) "Focus gain/lost" and (2) "resize of WebView" leads to crash. Any focus gain on WebView leads to query of GetTextLocation to show caret / cursor, If the page is not not rendered it will be scheduled for relayout. setsize (WebView width X Height) change also caused to relayout the webpage. Currently the crash occurs at random place (top of stack won't be same). Both the call to (1) and (2) are valid and should force the Layout if the page is not rendered completely. Will update further finding. Note : JFXTest is an Swing application and If i try to reproduce the crash using Simple helloWebView and doing the same steps doesn't lead to crash. But this will not conclude the crash is Event timing.
09-02-2018

+1
29-01-2018

[~arajkumar] tried with below content in Junit test but didn't observe crash where as same content with HelloWebView leads to crash. a. "<head> <meta content='text/html; charset=utf-8'> </head> <body> <a href='' lang='roa-x-eml'>ò</a> </body>" b. <meta content='text/html; charset=utf-8'> <a href='' lang='roa-x-eml'>ò</a> </body>" loading from file is the closest Unit test i could think of now.
29-01-2018

+1
29-01-2018

lgtm. >>however WebView.loadContent("<a href="" lang="roa-x-eml">ò</a>"); will not crash, where as loading from an html file containing this simplified 'lang' identifier 'roa-x-eml' along with a content 'ò'. Probably because it will be considered as 'Unicode' string instead of 'UTF-8'? Using 'data' URI scheme may help, load("data:text/plain;charset=UTF-8,'<a href='' lang='roa-x-eml'>ò</a>")
29-01-2018

webrev : http://cr.openjdk.java.net/~ghb/8196011/webrev.00/ Cherry pick the solution from "http://bugs.icu-project.org/trac/changeset/39286" Root cause and its work around updated in http://bugs.icu-project.org/trac/ticket/12705 Tested with simple HelloWebView with loading http://www.wikipedia.org or create a simple html file with content "<a href="" lang="roa-x-eml">ò</a>". however WebView.loadContent("<a href="" lang="roa-x-eml">ò</a>"); will not crash, where as loading from an html file containing this simplified 'lang' identifier 'roa-x-eml' along with a content 'ò'. I observed this problem only on 32bit (client) JDK, tried testing JFXTest using 8u161b12 x64 didn't crash on my PC (with or without my fix). roa-x-eml : lang identifier of Emilian egl and Romagnoal rgn. Didn't get much info about why only with this unknown identifier (not specified in icu lang list) crashes.
25-01-2018

When ran reproducible test case - JFXTest.java, i am able to reproduce crash using 8u161-b12 & 8u162-b03 on windows 64-bit. PFA error report files - hs_err_pid19872.log & hs_err_pid11292.log
25-01-2018

Tested latest 8u-dev code with 8u172+b03 , 32 bit on windows 7 and crash is observed while loading the site http://www.wikipedia.org/. However, i am not able to get crash with 8u161, 8u162 and 8u172 builds on 64 bit. Attached is the callstack (hs_err_pid12760.log). Below is the native callstack: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5d2ba0d2, pid=12760, tid=0x00002cdc # # JRE version: Java(TM) SE Runtime Environment (8.0_172-b03) (build 1.8.0_172-ea-b03) # Java VM: Java HotSpot(TM) Client VM (25.172-b03 mixed mode windows-x86 ) # Problematic frame: # C [jfxwebkit.dll+0x82a0d2] _isAlphaNumericString+0x12 # # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [jfxwebkit.dll+0x82a0d2] _isAlphaNumericString+0x12 C [jfxwebkit.dll+0x82a28c] _isPrivateuseVariantSubtag+0x2c C [jfxwebkit.dll+0x82abad] ultag_parse+0x4fd C [jfxwebkit.dll+0x82a3ef] uloc_forLanguageTag_51+0x1f C [jfxwebkit.dll+0x807f2d] _canonicalize+0xad C [jfxwebkit.dll+0x809676] uloc_getName_51+0x16 C [jfxwebkit.dll+0x7e783c] icu_51::Locale::init+0x11c C [jfxwebkit.dll+0x7e6ae3] icu_51::Locale::Locale+0x353 C [jfxwebkit.dll+0x7d7c61] ubrk_open_51+0xa1 C [jfxwebkit.dll+0x1119fef] WTF::LineBreakIteratorPool::take+0xff C [jfxwebkit.dll+0x1118de5] WTF::acquireLineBreakIterator+0x15 C [jfxwebkit.dll+0x601647] WTF::LazyLineBreakIterator::get+0xc7 C [jfxwebkit.dll+0x5fe5b3] WebCore::nextBreakablePosition<wchar_t,0,0>+0x163 C [jfxwebkit.dll+0x601f6e] WebCore::isBreakable+0x1ae C [jfxwebkit.dll+0x62edb4] WebCore::BreakingContext::handleText+0xad4 C [jfxwebkit.dll+0x630a75] WebCore::LineBreaker::nextLineBreak+0x2f5 C [jfxwebkit.dll+0x536e34] WebCore::RenderBlockFlow::layoutRunsAndFloatsInRange+0x3c4 C [jfxwebkit.dll+0x5369d2] WebCore::RenderBlockFlow::layoutRunsAndFloats+0x3b2 C [jfxwebkit.dll+0x53633d] WebCore::RenderBlockFlow::layoutLineBoxes+0x56d C [jfxwebkit.dll+0x52a1e0] WebCore::RenderBlockFlow::layoutBlock+0x380 C [jfxwebkit.dll+0x51a9fc] WebCore::RenderBlock::layout+0x6c C [jfxwebkit.dll+0x52aaaf] WebCore::RenderBlockFlow::layoutBlockChild+0x21f C [jfxwebkit.dll+0x52b17b] WebCore::RenderBlockFlow::layoutBlockChildren+0x28b C [jfxwebkit.dll+0x52a1f0] WebCore::RenderBlockFlow::layoutBlock+0x390 C [jfxwebkit.dll+0x51a9fc] WebCore::RenderBlock::layout+0x6c C [jfxwebkit.dll+0x579c63] WebCore::RenderFlowThread::layout+0x73 C [jfxwebkit.dll+0x52b03c] WebCore::RenderBlockFlow::layoutBlockChildren+0x14c C [jfxwebkit.dll+0x52a1f0] WebCore::RenderBlockFlow::layoutBlock+0x390 C [jfxwebkit.dll+0x51a9fc] WebCore::RenderBlock::layout+0x6c C [jfxwebkit.dll+0x52aaaf] WebCore::RenderBlockFlow::layoutBlockChild+0x21f C [jfxwebkit.dll+0x52b17b] WebCore::RenderBlockFlow::layoutBlockChildren+0x28b C [jfxwebkit.dll+0x52a1f0] WebCore::RenderBlockFlow::layoutBlock+0x390 C [jfxwebkit.dll+0x51a9fc] WebCore::RenderBlock::layout+0x6c C [jfxwebkit.dll+0x52aaaf] WebCore::RenderBlockFlow::layoutBlockChild+0x21f C [jfxwebkit.dll+0x52b17b] WebCore::RenderBlockFlow::layoutBlockChildren+0x28b C [jfxwebkit.dll+0x52a1f0] WebCore::RenderBlockFlow::layoutBlock+0x390 C [jfxwebkit.dll+0x51a9fc] WebCore::RenderBlock::layout+0x6c C [jfxwebkit.dll+0x52aaaf] WebCore::RenderBlockFlow::layoutBlockChild+0x21f
24-01-2018

Additional Information from submitter: ---------------------------------------------------------------- Hi, I found now a sequence which reproduces the focus-change issue what we have at our application by using the provided JFXTest sample. You can change the url to "http://www.google.com" and will see that also some minimalistic pages are affected. Steps to reproduce: (1) Change the URL at line 31 to "http://www.google.com" 2. Execute the JFXTest program 3. Click on the "Open a JFrame button" 4. Move the window so that you can open a second WebBrowser by clicking on "Open a JFrame button" 5. Change the focus to another application e.g. Outlook, Chrome etc... 6. Go back to the second WebBrowser frame and: -> click on a link like "Playstore" -> or sometimes it also work if you wait a few seconds.. ----------------------------------------------------------------
24-01-2018

Tested with JDK10 +40 windows 7, 64 bit and crash is not observed.
23-01-2018

Murali, does it affect 10 ?
23-01-2018

C:\Users\fmatte.ORADEV\Desktop\temp>"D:\Program Files\Java\jdk1.8.0_161\bin\java.exe" JFXTest # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000023297345, pid=6928, tid=0x000000000000247 8 # # JRE version: Java(TM) SE Runtime Environment (8.0_161-b12) (build 1.8.0_161-b12) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.161-b12 mixed mode windows-amd64 compressed oops) # Problematic frame: # C [jfxwebkit.dll+0x5b7345] # # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # # An error report file with more information is saved as: # C:\Users\fmatte.ORADEV\Desktop\temp\hs_err_pid6928.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. #
23-01-2018

[~fmatte] Since you have an environment in which you can reproduce a crash on 8u162 64-bit, can you also try with 8u161?
23-01-2018

Native call stack C [jfxwebkit.dll+0x863032] _isAlphaNumericString+0x12 C [jfxwebkit.dll+0x8631ec] _isPrivateuseVariantSubtag+0x2c C [jfxwebkit.dll+0x863b1b] ultag_parse+0x50b C [jfxwebkit.dll+0x86334f] uloc_forLanguageTag_51+0x1f C [jfxwebkit.dll+0x840acd] _canonicalize+0xad C [jfxwebkit.dll+0x8421f6] uloc_getName_51+0x16 C [jfxwebkit.dll+0x8201ad] icu_51::Locale::init+0x11d C [jfxwebkit.dll+0x81f442] icu_51::Locale::Locale+0x322 C [jfxwebkit.dll+0x810241] ubrk_open_51+0xa1 C [jfxwebkit.dll+0x11d41c3] WTF::LineBreakIteratorPool::take+0x103 C [jfxwebkit.dll+0x11d2f65] WTF::acquireLineBreakIterator+0x15 C [jfxwebkit.dll+0x62b3f9] WTF::LazyLineBreakIterator::get+0xc9 C [jfxwebkit.dll+0x6277d3] WebCore::nextBreakablePosition<wchar_t,0,0>+0x163 ...
23-01-2018

I tried on 64bit, and could crash on 8u162 and not on 8u152. == C:\Users\fmatte.ORADEV\Desktop\temp>"d:\Program Files\Java\jdk1.8.0_162\bin\java.exe" JFXTest # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000006de1ef56, pid=8000, tid=0x0000000000002ce 0 # # JRE version: Java(TM) SE Runtime Environment (8.0_162-b12) (build 1.8.0_162-b12) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.162-b12 mixed mode windows-amd64 compressed oops) # Problematic frame: # C [jfxwebkit.dll+0x53ef56] # # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # # An error report file with more information is saved as: # C:\Users\fmatte.ORADEV\Desktop\temp\hs_err_pid8000.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug.
23-01-2018

I can reproduce a crash in WebView when loading http://www.wikipedia.com on the 32-bit JDK 8u152 and 8u162. It runs fine for me on the 64-bit JDK 8u152 and 8u162. I cannot confirm a case where 8u152 works and 8u162 crashes. And given the changes that went into 8u161 (only 1 isolated fix that touched any webkit code) it would be even more unlikely to find a case that works on 8u152 and fails on 8u161.
22-01-2018