JDK-8150631 : jfxwebkit.dll VM crash in com.sun.webkit.Timer.twkFireTimerEvent
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8u71
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2016-02-25
  • Updated: 2016-08-27
  • Resolved: 2016-08-22
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.
Related Reports
Relates :  
Relates :  
jfxwebkit.dll VM crash in com.sun.webkit.Timer.twkFireTimerEvent  (EXCEPTION_ACCESS_VIOLATION)

From From hs_err_pid3880.log
# A fatal error has been detected by the Java Runtime Environment:
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6ba3c043, pid=3880,tid=4148
# JRE version: Java(TM) SE Runtime Environment (8.0_71-b15) (build 1.8.0_71-b15)
# Java VM: Java HotSpot(TM) Client VM (25.71-b15 mixed mode windows-x86 )
# Problematic frame:
# C  [jfxwebkit.dll+0xa9c043]
# 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.

---------------  T H R E A D  ---------------

Current thread (0x47435000):  JavaThread "JavaFX Application Thread"
[_thread_in_native, id=4148, stack(0x50710000,0x50810000)]

siginfo: ExceptionCode=0xc0000005, writing address 0xbbadbeef

EAX=0x00000000, EBX=0x66fda910, ECX=0x00000001, EDX=0x00000000
ESP=0x5080d0cc, EBP=0x000ba9a7, ESI=0x00000000, EDI=0x000ba9a7
EIP=0x6ba3c043, EFLAGS=0x00010206

Top of Stack: (sp=0x5080d0cc)
0x5080d0cc:   6ba3c02b 00000000 000ba9b0 00000000
0x5080d0dc:   00000018 5080d11c 6e8848ca 6cf40e10
0x5080d0ec:   5080d130 4a1eba9c 5080d118 6e8df57e
0x5080d0fc:   4a1eba9c 6cf40e10 4a1eba9c 774e18e0
0x5080d10c:   00000000 6cf40e10 000ba9a7 5080d124
0x5080d11c:   6e87ed29 00000007 5080d14c 6e87f747
0x5080d12c:   00000008 00000000 000ba9a7 6e881782
0x5080d13c:   6e8cdace 000ba9a7 66fda910 000ba9a7

Instructions: (pc=0x6ba3c043)
0x6ba3c023:   04 51 6a 21 6a 00 ff d0 0f b7 c0 eb 02 33 c0 83
0x6ba3c033:   c0 fe 50 8d 44 24 0c 50 e8 50 05 00 00 83 c4 08
0x6ba3c043:   c7 05 ef be ad bb 00 00 00 00 33 c0 ff d0 8b 8c
0x6ba3c053:   24 84 00 00 00 33 cc e8 bd ee 2b 00 81 c4 88 00

Register to memory mapping:

EAX=0x00000000 is an unknown value
EBX=0x66fda910 is an unknown value
ECX=0x00000001 is an unknown value
EDX=0x00000000 is an unknown value
ESP=0x5080d0cc is pointing into the stack for thread: 0x47435000
EBP=0x000ba9a7 is an unknown value
ESI=0x00000000 is an unknown value
EDI=0x000ba9a7 is an unknown value

Stack: [0x50710000,0x50810000],  sp=0x5080d0cc,  free space=1012k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
C  [jfxwebkit.dll+0xa9c043]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 7883  com.sun.webkit.Timer.twkFireTimerEvent()V (0 bytes) @ 0x02bc5999 [0x02bc5960+0x39]
J 7882 C1 com.sun.webkit.Timer.fireTimerEvent(J)V (65 bytes) @ 0x02b4621c [0x02b45fd0+0x24c]
J 7881 C1 com.sun.webkit.Timer.notifyTick()V (29 bytes) @ 0x02b46a74 [0x02b46950+0x124]
J 7025 C1 javafx.scene.web.WebEngine$PulseTimer$$Lambda$86.pulse()V (4 bytes) 0x02a8bcbc [0x02a8bc90+0x2c]
J 3462 C1 com.sun.javafx.tk.Toolkit$$Lambda$99.run()Ljava/lang/Object; (8 bytes) @ 0x02bcd5b8 [0x02bcd590+0x28] v  ~StubRoutines::call_stub
J 1246 java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object; (0 bytes) @0x02b542c7 [0x02b54260+0x67]
J 3406 C1 com.sun.javafx.tk.Toolkit.firePulse()V (279 bytes) @ 0x02b71240 [0x02b70c70+0x5d0]
J 7464 C1 com.sun.javafx.tk.quantum.QuantumToolkit.pulse(Z)V (164 bytes) @ 0x02bea670 [0x02bea5d0+0xa0]
J 7014 C1 com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$66.run()V (8 bytes) @ 0x02a037fc [0x02a037d0+0x2c]
J 5480 C1 com.sun.glass.ui.InvokeLaterDispatcher$Future.run()V (91 bytes) @ 0x02cd4b70 [0x02cd4b40+0x30] v  ~StubRoutines::call_stub
j  com.sun.glass.ui.win.WinApplication._runLoop(Ljava/lang/Runnable;)V+0
j com.sun.glass.ui.win.WinApplication.lambda$null$148(ILjava/lang/Runnable;)V+8
j  com.sun.glass.ui.win.WinApplication$$Lambda$62.run()V+12
j  java.lang.Thread.run()V+11 v  ~StubRoutines::call_stub
needs to link to JDK-8153501

According to the JavaScript code in webworker.html and webworker.js: when the first message is posted to web worker, it starts sending the messages in infinity loop. That causes many memory allocations for new messages and as a result the memory owned by the browser's process grows very quickly. At some point we cannot create new message any more and crashes due to lack of memory. In other words the test case consumes all memory, but does not have any functionality intended for memory cleaning. So the crash in JavaFX is just a side effect of 'memory leak' which is triggered by some buggy JavaScript code from webworker.html and webworker.js.

It looks like we have a memory leak somewhere in Webkit code. In 'Process Explorer' I can see that the native memory of Java process grows very quickly and at the some point (on my machine it is about 1.5 Gb) we crashes due to lack of memory. Also I was able to reproduce quite similar crash (memory leak) without JavaFX. I used only webworker.html and webworker.js (see attachment) from the test case attached to JDK-8145487. I used the following steps to reproduce the crash w/o JavaFX: 1. Deploy webworker.html and webworker.js to any server 2. Open webworker.html in the browser, (e.g. FireFox) 3. Browser becomes unresponsive and will crash in 5-7 minutes (the memory owned by the browser's process grows very quickly; it maybe observed from TaskManager or any other tool) The crash is reproducible on Chrome and FireFox.

Test case to reproduce the crash without JavaFX attached

I can reproduce the problem using test case from JDK-8145487