JDK-8094733 : JVM crash when running Google WebKit benchmarks
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 7u10,7u45
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-01-18
  • Updated: 2015-06-12
  • Resolved: 2014-01-17
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 7
7u55Fixed
Related Reports
Duplicate :  
JDK-8094269 - Crash in webkit timer
Duplicate :  
JDK-8092582 - [WebNode] jfxwebkit.dll crash when playing Youtube videos in WebView
Relates :  
JDK-8092582 - [WebNode] jfxwebkit.dll crash when playing Youtube videos in WebView
Description
http://v8.googlecode.com/svn/data/benchmarks/v7/run.html

Run the Google benchmarks - seems to work reliably the first time through but if I then hit browser.reload or browser.load again it gets half-way through the benchmark run and crashes the JVM. Duplicated under your WebViewSample browser.

JVM stack is -

Stack: [0x0bdf0000,0x0be40000],  sp=0x0be3ec5c,  free space=315k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [jfxwebkit.dll+0x74ddab]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  com.sun.webpane.webkit.Timer.twkFireTimerEvent()V+0
j  com.sun.webpane.webkit.Timer.fireTimerEvent(J)V+45
j  com.sun.webpane.webkit.Timer.notifyTick()V+25
j  javafx.scene.web.WebEngine$PulseTimer$2.pulse()V+3
J  com.sun.javafx.tk.Toolkit.firePulse()V
j  com.sun.javafx.tk.quantum.QuantumToolkit.pulse()V+100
j  com.sun.javafx.tk.quantum.QuantumToolkit$9.run()V+4
v  ~StubRoutines::call_stub
j  com.sun.glass.ui.win.WinApplication._runLoop([Ljava/lang/String;Lcom/sun/glass/ui/Launchable;)V+0
j  com.sun.glass.ui.win.WinApplication.access$100(Lcom/sun/glass/ui/win/WinApplication;[Ljava/lang/String;Lcom/sun/glass/ui/Launchable;)V+3
j  com.sun.glass.ui.win.WinApplication$3$1.run()V+32
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub
Comments
SQE OK to take this customer escalation bug fix into CPU14_02.
16-01-2014
CPU14_02-critical-request justification: This is the ICE customer escalation and we would like to see the fix in the 2.2.55. Though the fix is small, it is in a critical area - GC of the Javascript engine. The fix was intensively tested with different benchmarks which heavily utilize the JS GC, see above for more info.
16-01-2014
As far as know the BPR was not requested by customer or service.
18-12-2013
The test for this particular problem is attached. Here are WebNode test suite run instructions: http://wiki.se.oracle.com/display/JPGSE/JavaFX+Sustaining#JavaFXSustaining-TestingWebNode There are some fails and I've compared the results with and without the fix. Additionally I've run the following JS benchmark tests (its worth to run them several times by clicking right button and pushing 'Refresh'): http://v8.googlecode.com/svn/data/benchmarks/v7/run.html (which crashed on the second reload) http://www.webkit.org/perf/sunspider/sunspider.html http://krakenbenchmark.mozilla.org/ http://octane-benchmark.googlecode.com/svn/latest/index.html I would rate the risk as Medium: from one side the JS Memory Management is a sensitive module, from the other side testing with large suite and several heavy loading JS benchmarks makes some confidence that no regressions are introduced. We would like the fix to be included as soon as possible since this is a customer escalation.
18-12-2013
Added a 2260-critical-watch label. When the fix is ready and reviewed, please change this to "2260-critical-request-dev"
26-11-2013
The problem was found in the Webkit Javascript Garbage collector. The JFX 8.0 is now regularly merged with the Webkit workspace while the JFX 2 is not, that's why this issue is not reproducible in JFX 8.0. The memory management workspaces are now very different between JFX2 and JFX8 so this fix is not a backport but rather an independent fix in an older Webkit.
26-11-2013
Reduced testcase. Example to run: C:\jdk1.7.0_45b10\jre\bin\java.exe -cp .;C:\jdk1.7.0_45b10\jre\lib\jfxrt.jar SimpleWebView file:///C:/ws/bugs/16210948/run.html
26-11-2013
Sorry -- this bug affects 7u only
13-11-2013
Please provide deferral justification.
12-11-2013
Almost the same issue here. When creating a new WebView instance every time when loading a new page, twkFireTimerEvent() will eventually start throwing NPE's and then crash the JVM the same way as mentioned above.(for loading http://www.cofely-gdfsuez.nl/nl/over-cofely/vestigingen.html which has an embedded google map, and also for loading http://maps.google.nl) Tried this on JDK 1.7u7 and 1.7u40. However, it almost seems random when these crashes occur. Sometimes instantly, sometimes after 10+ times.
08-10-2013
FYI - Upgrading to Java 7u13 is causing crashing in our application - will write another ticket for that. Rolling back to 7u11 resolves the issue.
04-02-2013
Peter - Thanks and interesting since your frontline people said they had been able to reproduce it. I did just download 7u13 and it reproduced/crashed at exactly the same place. It identifies itself as JavaFX 2.2.5b09. Crash stack is - # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x586ae50b, pid=11152, tid=4624 # # JRE version: 7.0_13-b20 Stack: [0x04c90000,0x04ce0000], sp=0x04cdeb1c, free space=314k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [jfxwebkit.dll+0x74e50b] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j com.sun.webpane.webkit.Timer.twkFireTimerEvent()V+0 j com.sun.webpane.webkit.Timer.fireTimerEvent(J)V+45 j com.sun.webpane.webkit.Timer.notifyTick()V+25 ... When you say you were able to run the test >10 times were you hitting the reload option on the right-click menu, or what ? The first run through always seems to succeed, its the second run that always fails.
04-02-2013
Well I didn't dig that deep but I was able to run the benchmark >10 times. BTW you may want to try 7u13 as this bug may already be fixed there.
04-02-2013
Peter - Thanks for that and yes I believe part of the problem is a memory overflow BUT you probably also want to look at why the tests run successfully the first time and then fail the second time around. To me this sounds like something is not getting cleaned-up properly, maybe an issue with the garbage collection routines ??
31-01-2013
This is going to be fixed in Lombard, presumably by one of the stack overflow fixes.
31-01-2013
Hotspot error log hs_err_pid9220.log
24-01-2013
Cant seem to attach full hs_err_pid file, no "attach file" option on Jira menu.
18-01-2013