JDK-8152551 : Null pointer crash in JSC::speculationFromCell (jfxwebkit.dll)
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8u72,9
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2016-03-23
  • Updated: 2020-01-31
  • Resolved: 2016-04-11
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 9
9Resolved
Related Reports
Duplicate :  
Relates :  
Description
JAVAFX: JRE crash in com.sun.webkit.Timer.twkFireTimerEvent is crashing
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x528bce4b, pid=5488, tid=0x00001458
#
# JRE version: Java(TM) SE Runtime Environment (8.0_76-b09) (build 1.8.0_76-b09)
# Java VM: Java HotSpot(TM) Client VM (25.76-b09 mixed mode windows-x86 )
# Problematic frame:
# C  [jfxwebkit.dll+0x11ece4b]  JSC::speculationFromCell+0xb
#
# 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 (0x15b96400):  JavaThread "JavaFX Application Thread" [_thread_in_native, id=5208, stack(0x17170000,0x171c0000)]

siginfo: ExceptionCode=0xc0000005, reading address 0x00000418

Registers:
EAX=0x00000000, EBX=0x218415d8, ECX=0x00000000, EDX=0x171be358
ESP=0x171be2f8, EBP=0x000000a0, ESI=0x218415e8, EDI=0x00000002
EIP=0x528bce4b, EFLAGS=0x00010246

Top of Stack: (sp=0x171be2f8)
0x171be2f8:   528bd04e 00000000 52796ad4 00000000
0x171be308:   fffffffb 33ee0028 218415d8 00000005
0x171be318:   527a1cba 171be330 3f3df980 33ee0028
0x171be328:   1b772e10 00000000 00000000 1b772e10
0x171be338:   527a1726 171be358 171be360 33ee0028
0x171be348:   1b772d20 0000014c 1b772e10 163efff0
0x171be358:   00000002 527a2e64 00000006 1b772e10
0x171be368:   2c0ce590 1b76ddf0 1b772f10 5277242f 

Instructions: (pc=0x528bce4b)
0x528bce2b:   94 c0 c3 cc cc 33 c0 81 7c 24 04 00 01 00 00 0f
0x528bce3b:   94 c0 c3 cc cc 8b 4c 24 04 8b c1 25 00 00 ff ff
0x528bce4b:   83 b8 18 04 00 00 02 75 05 8b 41 08 eb 05 8b 01
0x528bce5b:   8b 40 20 85 c0 74 0e 3d f8 00 d5 52 74 2b 8b 40 


Register to memory mapping:

EAX=0x00000000 is an unknown value
EBX=0x218415d8 is an unknown value
ECX=0x00000000 is an unknown value
EDX=0x171be358 is pointing into the stack for thread: 0x15b96400
ESP=0x171be2f8 is pointing into the stack for thread: 0x15b96400
EBP=0x000000a0 is an unknown value
ESI=0x218415e8 is an unknown value
EDI=0x00000002 is an unknown value


Stack: [0x17170000,0x171c0000],  sp=0x171be2f8,  free space=312k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [jfxwebkit.dll+0x11ece4b]  JSC::speculationFromCell+0xb

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 2867  com.sun.webkit.Timer.twkFireTimerEvent()V (0 bytes) @ 0x02d09dd9 [0x02d09da0+0x39]
J 2866 C1 com.sun.webkit.Timer.fireTimerEvent(J)V (65 bytes) @ 0x02c4371c [0x02c434d0+0x24c]
J 2865 C1 com.sun.webkit.Timer.notifyTick()V (29 bytes) @ 0x02d05cb4 [0x02d05b90+0x124]
J 2704 C1 javafx.scene.web.WebEngine$PulseTimer$$Lambda$110.pulse()V (4 bytes) @ 0x02cb127c [0x02cb1250+0x2c]
J 1219 C1 com.sun.javafx.tk.Toolkit$$Lambda$130.run()Ljava/lang/Object; (8 bytes) @ 0x02d33ff8 [0x02d33fd0+0x28]
v  ~StubRoutines::call_stub
J 551  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object; (0 bytes) @ 0x02c38987 [0x02c38920+0x67]
J 1215 C1 com.sun.javafx.tk.Toolkit.firePulse()V (279 bytes) @ 0x02d32c00 [0x02d32630+0x5d0]
J 2768 C1 com.sun.javafx.tk.quantum.QuantumToolkit.pulse(Z)V (164 bytes) @ 0x02cf3304 [0x02cf3250+0xb4]
J 2691 C1 com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$44.run()V (8 bytes) @ 0x02cda97c [0x02cda950+0x2c]
J 1503 C1 com.sun.glass.ui.InvokeLaterDispatcher$Future.run()V (91 bytes) @ 0x02da13f0 [0x02da13c0+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$3(ILjava/lang/Runnable;)V+8
j  com.sun.glass.ui.win.WinApplication$$Lambda$40.run()V+12
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub


Comments
Closed as dupe of JDK-8153501, see justification above
11-04-2016

@kevin, This fix is not needed now since this crash is part of heap corruption issue and heap corruption issue is resolved as part of JDK-8153501. We can make this issue as duplicate of JDK-8153501.
09-04-2016

[~dmarkov] Thanks for the test results. As per JSC crashes in test results, i guess "JSC::SlotVisitor::drain" is reproducible even without your fix and no other new JSC crashes are visible as per your test results (with your fix). patch looks fine.. +1
01-04-2016

Per discussion with Murali: We are going to perform some testing on the build with fix and without fix just to make sure that the fix will not introduce any regression/crash. I will perform tests and provide results.
31-03-2016

As far as I know specNone is a default value, (i.e. it means that something is uninitialized); specOther is intended for something undefined, (i.e. something we can't recognize). So I believe specNone is more suitable here. I agree that is not an ideal solution, but it avoids the crash. Also we do not have any information about other problems/crashes caused by the fix.
31-03-2016

The proposed fix is not a webkit changeset. One Concern is the fix might be avoiding the crash with NULL check and can crash elsewhere?
31-03-2016

lgtm
31-03-2016

[~dmarkov] is return value will be specNone or specOther ? is ther any difference in this case?
30-03-2016

+1 Looks good to me
30-03-2016

Proposed fix: http://cr.openjdk.java.net/~dmarkov/8152551/webrev.00/
23-03-2016