JDK-8147851 : jvm crash at javafx com.sun.webkit.WebPage.twkPrePaint
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-01-20
  • Updated: 2020-02-24
  • Resolved: 2016-03-02
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 JDK 9
8u102Fixed 9Fixed
Related Reports
Relates :  
JDK-8166677 - HTMLEditor freezes after restoring previously maximized window
Relates :  
JDK-8151044 - Cleanup whitespace in WebView.java after fix for JDK-8147851
Description
Swing application which uses JFXPanel to embed a JavaFX WebView crashes at random times. We do load a fairly large amount of data into the WebView, but it should be no more than 1-2 MB.

The crash usually happens in: com.sun.webkit.WebPage.twkPrePaint
Comments
Changeset: 57564ab53438 Author: kcr Date: 2016-03-01 17:28 -0800 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/57564ab53438
02-03-2016
+1 Looks good to me.
02-03-2016
This fix looks good to me. +1 During the review I discovered a potential issue for which I will file a follow-on bug: It looks like we should not be allocating the WebView render buffers at the point they are being allocated. Currently this is done in the stage pulse listener, but it seems more appropriate as part of the the scene graph sync portion of the pulse.
02-03-2016
Proposed fix is in WebView.java -> handleStagePulse() which basically decides to update the current bits. This code also creates render queues which hold buffers for rendering. This code checks if the window is actually visible or not. but this code does not cover the conditions a. when the size of window is in negative, basically its not displayed on screen at all. b. If its iconified using stage.setIconified(true) If we look at SceneState->isValid() and ViewPainter->validateStageGraphics() methods they covers iconified and the width and height of the state. these methods are used in deciding if current state is renderable or not. Due to the mismatch on how we decide if state is valid , we are generating more render queues/buffers than we can process. we need to use same conditions in both places. webrev : http://cr.openjdk.java.net/~kcr/nnatu/8147851/webrev.00/
02-03-2016
Crash is caused due to leaking of memory in RenderingQueue. We listen to stage pulse in WebView. In that we check for if its really visible or not. that check does not take into account size of view. If its visible we update the dirty bits needed for rendering. But corresponding render thread does depend on the size of stage. So basically we keep on generating RenderingQueue and in turn buffer associated with it , but don't do anything (decode/dispose). That leads to exhausting of memory and in turn crash.
01-03-2016
twkPrePaint : recursively traverse to all the RenderObjects and invalidates the dirty rects. Crash occurred in Native (jfxwebkit.dll). As pointed out earlier, repeated JavaScript is being executed, There could be situation where JavaScript parsing error (on both content as well as on the parsing side). Is it possible to share a debug of JavaFX and also get the console logs for "com.sun.webkit" package.
20-01-2016
Since WebKit is identical between FX 8u and FX 9, this will almost certainly affect FX 9 as well.
20-01-2016
Customer's observation on the problem: =========>>> It does not always crash--only every now and then, which makes it much harder to diagnose. This happens on multiple versions of the JVM. It has been observed on u51, u60, and u66. The customer has not tried earlier versions. We have recently moved to use JavaFX instead of using a product like JExplorer, and can't make the customer try that many old versions. This means that we don't have a long history of using JavaFX for this. I am working on trying to come up with a repeatable simplified scenario, but the is a fairly large amount of code involved. One of the things that I believe contributes is that there are a significant number of calls to execute java script in the JavaFX thread, from the AWT Thread...waiting for the response, which does block the AWT thread briefly. I was hoping you could provide some more insight into what is likely happening twkPrePaint. From browsing logs, this seems to be a somewhat common problem.
20-01-2016
Customer has frequent intermittent jvm crashes in production environment and has urgency to get the fix.
20-01-2016