Bug ID: JDK-8094269 Crash in webkit timer

JDK 8
8u40Resolved

The crash with the Octane Benchmark is just an out of native memory problem. I was able to reproduce the problem with -Xmx1G. When -Xmx1G is specified the process has less native memory to allocate and thus fails with a higher probability. The Webkit x32 just fails to allocate memory at some point (OSAllocator::reserveUncommitted) and calls the WTFCrash procedure which just writes data to [0xbbadbeef] (see the dump). This is the regular Webkit behavior in Release build. I've reproduced the same behavior with just infinitely allocating arrays in JS. In such cases the x64 JRE/JFX version could be used. However the original crash was different, but we have no testcase to reproduce it. Closing again as 'couldn't reproduce'
23-10-2014
On Mac, the crash no longer happens for me. I am loading running the example code from the comment that loads http://octane-benchmark.googlecode.com/svn/latest/index.html
14-10-2014
Hi, I managed to reproduce the crash on Linux. I took a 32 bit Fedora 20 system, 32 bit JDK 8u5 and the following command line: (ulimit -v 1500000; java -Xmx1g -jar ...) So I limit the process virtual memory to 1.5 Gig and run with 1 Gig maximum heap. The stack trace is a little different than on Windows (much more informative), but the crash happens in the same native function (Java_com_sun_webkit_Timer_twkFireTimerEvent). I can also produce a core dump. Would it help? Here's a paste of the hs_err_pidXXXX.log: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x71785665, pid=11758, tid=1930865472 # # JRE version: Java(TM) SE Runtime Environment (8.0_05-b13) (build 1.8.0_05-b13) # Java VM: Java HotSpot(TM) Client VM (25.5-b02 mixed mode linux-x86 ) # Problematic frame: # C [libjfxwebkit.so+0x1400665] WTFReportBacktrace+0xb5 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # http://bugreport.sun.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 (0x73871800): JavaThread "JavaFX Application Thread" [_thread_in_native, id=11769, stack(0x7311a000,0x7316b000)] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0xbbadbeef Registers: EAX=0x00000000, EBX=0x720eaff4, ECX=0x0000001f, EDX=0x479e3898 ESP=0x73168760, EBP=0x73168768, ESI=0xffffffff, EDI=0x0001f000 EIP=0x71785665, EFLAGS=0x00010246, CR2=0xbbadbeef The complete crash log is attached as RT-33599-crash4.log
12-09-2014
The hs_errXXX.pid on JDK 8 / JavaFX 8 is very simmilar to that on JDK 7 / JavaFX 2.2.45, but a little different too. Here it is (8u5, 32bit, Windows): # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5f420472, pid=7336, tid=2280 # # JRE version: Java(TM) SE Runtime Environment (8.0_05-b13) (build 1.8.0_05-b13) # Java VM: Java HotSpot(TM) Client VM (25.5-b02 mixed mode windows-x86 ) # Problematic frame: # C [jfxwebkit.dll+0xa10472] # # 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.sun.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 (0x43829800): JavaThread "JavaFX Application Thread" [_thread_in_native, id=2280, stack(0x43cf0000,0x43d40000)] siginfo: ExceptionCode=0xc0000005, writing address 0xbbadbeef Registers: EAX=0x00000000, EBX=0x0001f000, ECX=0x77965398, EDX=0x43d3e418 ESP=0x43d3e408, EBP=0x00010000, ESI=0x00000000, EDI=0x4682b2f0 EIP=0x5f420472, EFLAGS=0x00210282 The complete crash log is attached as RT-33599-crash3.log
12-09-2014
Unfortunately, the crash happened with j7u45 as well: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000007032ba66, pid=2660, tid=4812 # # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build 1.7.0_45-b18) # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode windows-amd64 compressed oops) # Problematic frame: # C [jfxwebkit.dll+0x7bba66] # # 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.sun.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 (0x0000000013a9f000): JavaThread "JavaFX Application Thread" [_thread_in_native, id=4812, stack(0x00000000165f0000,0x00000000166f0000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0000000000000018 Registers: RAX=0x0000000013541740, RBX=0x0000000013542048, RCX=0x00000000166ed970, RDX=0x00000000132ad3d0 RSP=0x00000000166ed8f0, RBP=0x0000000000000000, RSI=0x00000000166eda18, RDI=0x00000000166eda18 R8 =0x0000000000000000, R9 =0x0000000000000000, R10=0x0000000000000000, R11=0x0000000000000000 R12=0x0000000016e00201, R13=0x0000000000000003, R14=0x000000000fa95058, R15=0x0000000016e00248 RIP=0x000000007032ba66, EFLAGS=0x0000000000010206 The rest of the crash log is attached as RT-33599-crash2.log
12-09-2014
I managed to build 32 bit openjfx with debugging symbols included (even in WebKit). See this thread to find out how: http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-June/014248.html I managed to get a gdb backtrace from the crash: Core was generated by `java -Xmx1800m -jar webkit_test_purefx.jar file:///home/peter/localwork/octane/'. Program terminated with signal SIGABRT, Aborted. #0 0xf77a3430 in __kernel_vsyscall () (gdb) backtrace #0 0xf77a3430 in __kernel_vsyscall () #1 0xf75c6827 in raise () from /lib/i386-linux-gnu/libc.so.6 #2 0xf75c9c53 in abort () from /lib/i386-linux-gnu/libc.so.6 #3 0xf6ef7241 in os::abort(bool) () from /home/peter/Apps/jdk1.8.0_05-i386/jre/lib/i386/server/libjvm.so #4 0xf7066d50 in VMError::report_and_die() () from /home/peter/Apps/jdk1.8.0_05-i386/jre/lib/i386/server/libjvm.so #5 0xf6efd01b in JVM_handle_linux_signal () from /home/peter/Apps/jdk1.8.0_05-i386/jre/lib/i386/server/libjvm.so #6 0xf6ef3451 in signalHandler(int, siginfo, void) () from /home/peter/Apps/jdk1.8.0_05-i386/jre/lib/i386/server/libjvm.so #7 <signal handler called> #8 0x6591cc7e in WTFCrash () at ../../../../src/main/native/Source/WTF/wtf/Assertions.cpp:345 #9 0x65950c3f in WTF::OSAllocator::reserveUncommitted (bytes=126976, usage=WTF::OSAllocator::UnknownUsage, writable=true, executable=false, includesGuardPages=false) at ../../../../src/main/native/Source/WTF/wtf/OSAllocatorPosix.cpp:58 #10 0x65ac9033 in WTF::PageAllocationAligned::allocate (size=65536, alignment=65536, usage=WTF::OSAllocator::UnknownUsage, writable=true) at ../../../../src/main/native/Source/WTF/wtf/PageAllocationAligned.cpp:55 #11 0x65b5bff7 in JSC::DFG::Allocator<JSC::DFG::Node>::allocateSlow (this=0x70df9f78) at ../../../../src/main/native/Source/JavaScriptCore/dfg/DFGAllocator.h:204 #12 0x65b5a7c0 in JSC::DFG::Allocator<JSC::DFG::Node>::freeListAllocate (this=0x70df9f78) at ../../../../src/main/native/Source/JavaScriptCore/dfg/DFGAllocator.h:190 #13 0x65b58e4a in JSC::DFG::Allocator<JSC::DFG::Node>::allocate (this=0x70df9f78) at ../../../../src/main/native/Source/JavaScriptCore/dfg/DFGAllocator.h:109 #14 0x65b53d53 in operator new (size=84, allocator=...) at ../../../../src/main/native/Source/JavaScriptCore/dfg/DFGNodeAllocator.h:45 #15 0x65b5bbb1 in JSC::DFG::Graph::addNode<JSC::DFG::NodeType, JSC::CodeOrigin, JSC::DFG::OpInfo> (this=0x68a9effc, type=0, _DFG_value1=@0x68a9de3c: JSC::DFG::Phi, _DFG_value2=..., _DFG_value3=...) at ../../../../src/main/native/Source/JavaScriptCore/dfg/DFGGraph.h:166 #16 0x65ce34a7 in JSC::DFG::CPSRethreadingPhase::addPhiSilently (this=0x68a9dfd8, block=0x88d5970, codeOrigin=..., variable=0x89501b0) at ../../../../src/main/native/Source/JavaScriptCore/dfg/DFGCPSRethreadingPhase.cpp:133 #17 0x65ce532c in JSC::DFG::CPSRethreadingPhase::addPhi<(JSC::OperandKind)1> (this=0x68a9dfd8, block=0x88d5970, codeOrigin=..., variable=0x89501b0, index=5) at ../../../../src/main/native/Source/JavaScriptCore/dfg/DFGCPSRethreadingPhase.cpp:141 #18 0x65ce5492 in JSC::DFG::CPSRethreadingPhase::addPhi<(JSC::OperandKind)1> (this=0x68a9dfd8, codeOrigin=..., variable=0x89501b0, index=5) at ../../../../src/main/native/Source/JavaScriptCore/dfg/DFGCPSRethreadingPhase.cpp:149 #19 0x65ce4c43 in JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor<(JSC::OperandKind)1> (this=0x68a9dfd8, node=0x43f389d0, variable=0x89501b0, idx=5) at ../../../../src/main/native/Source/JavaScriptCore/dfg/DFGCPSRethreadingPhase.cpp:213 #20 0x65ce3559 in JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocal (this=0x68a9dfd8, node=0x43f389d0) at ../../../../src/main/native/Source/JavaScriptCore/dfg/DFGCPSRethreadingPhase.cpp:225 #21 0x65ce373c in JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock (this=0x68a9dfd8) at ../../../../src/main/native/Source/JavaScriptCore/dfg/DFGCPSRethreadingPhase.cpp:361 #22 0x65ce3828 in JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlocks (this=0x68a9dfd8) at ../../../../src/main/native/Source/JavaScriptCore/dfg/DFGCPSRethreadingPhase.cpp:392 #23 0x65ce30f4 in JSC::DFG::CPSRethreadingPhase::run (this=0x68a9dfd8) at ../../../../src/main/native/Source/JavaScriptCore/dfg/DFGCPSRethreadingPhase.cpp:52 #24 0x65ce5f5e in JSC::DFG::runAndLog<JSC::DFG::CPSRethreadingPhase> (phase=...) at ../../../../src/main/native/Source/JavaScriptCore/dfg/DFGPhase.h:75 #25 0x65ce50bd in JSC::DFG::runPhase<JSC::DFG::CPSRethreadingPhase> (graph=...) at ../../../../src/main/native/Source/JavaScriptCore/dfg/DFGPhase.h:85 #26 0x65ce2cfd in JSC::DFG::performCPSRethreading (graph=...) at ../../../../src/main/native/Source/JavaScriptCore/dfg/DFGCPSRethreadingPhase.cpp:493 #27 0x65b4e08a in JSC::DFG::compile (compileMode=JSC::DFG::CompileFunction, exec=0x6343bf48, codeBlock=0x43ce1308, jitCode=..., jitCodeWithArityCheck=0x5f52bb04, osrEntryBytecodeIndex=0) at ../../../../src/main/native/Source/JavaScriptCore/dfg/DFGDriver.cpp:122 #28 0x65b4d983 in JSC::DFG::tryCompileFunction (exec=0x6343bf48, codeBlock=0x43ce1308, jitCode=..., jitCodeWithArityCheck=..., bytecodeIndex=0) at ../../../../src/main/native/Source/JavaScriptCore/dfg/DFGDriver.cpp:182 #29 0x659ee25b in JSC::jitCompileFunctionIfAppropriate (exec=0x6343bf48, codeBlock=..., jitCode=..., jitCodeWithArityCheck=..., jitType=JSC::JITCode::DFGJIT, bytecodeIndex=0, effort=JSC::JITCompilationCanFail) at ../../../../src/main/native/Source/JavaScriptCore/jit/JITDriver.h:95 #30 0x659ee4a4 in JSC::prepareFunctionForExecution (exec=0x6343bf48, codeBlock=..., jitCode=..., jitCodeWithArityCheck=..., jitType=JSC::JITCode::DFGJIT, bytecodeIndex=0, kind=JSC::CodeForCall) at ../../../../src/main/native/Source/JavaScriptCore/runtime/ExecutionHarness.h:68 #31 0x659ebe91 in JSC::FunctionExecutable::compileForCallInternal (this=0x5f52bad8, exec=0x6343bf48, scope=0x61d5dbf0, jitType=JSC::JITCode::DFGJIT, bytecodeIndex=0) at ../../../../src/main/native/Source/JavaScriptCore/runtime/Executable.cpp:539 #32 0x659eb659 in JSC::FunctionExecutable::compileOptimizedForCall (this=0x5f52bad8, exec=0x6343bf48, scope=0x61d5dbf0, bytecodeIndex=0) at ../../../../src/main/native/Source/JavaScriptCore/runtime/Executable.cpp:464 #33 0x65ae4398 in JSC::FunctionExecutable::compileOptimizedFor (this=0x5f52bad8, exec=0x6343bf48, scope=0x61d5dbf0, bytecodeIndex=0, kind=JSC::CodeForCall) at ../../../../src/main/native/Source/JavaScriptCore/runtime/Executable.h:679 #34 0x65ae05cf in JSC::FunctionCodeBlock::compileOptimized (this=0x4b40f818, exec=0x6343bf48, scope=0x61d5dbf0, bytecodeIndex=0) at ../../../../src/main/native/Source/JavaScriptCore/bytecode/CodeBlock.cpp:2843 #35 0x659a406d in JSC::cti_optimize (args=0x68a9fcc0) at ../../../../src/main/native/Source/JavaScriptCore/jit/JITStubs.cpp:1964 ---Type <return> to continue, or q <return> to quit--- #36 0x659a0ce1 in JSC::tryCacheGetByID (callFrame=0x0, codeBlock=0xfffffffb, returnAddress=..., baseValue=..., propertyName=..., slot=..., stubInfo=0x0) at ../../../../src/main/native/Source/JavaScriptCore/jit/JITStubs.cpp:1068 #37 0x6343bad8 in ?? () #38 0x65994da7 in JSC::JITCode::execute (this=0x5f5237ac, stack=0x70df9cf0, callFrame=0x6343a058, vm=0x70df3df8) at ../../../../src/main/native/Source/JavaScriptCore/jit/JITCode.h:135 #39 0x659922bc in JSC::Interpreter::executeCall (this=0x70df9ce8, callFrame=0x6253f994, function=0x5eedf618, callType=JSC::CallTypeJS, callData=..., thisValue=..., args=...) at ../../../../src/main/native/Source/JavaScriptCore/interpreter/Interpreter.cpp:1052 #40 0x659dc14c in JSC::call (exec=0x6253f994, functionObject=..., callType=JSC::CallTypeJS, callData=..., thisValue=..., args=...) at ../../../../src/main/native/Source/JavaScriptCore/runtime/CallData.cpp:40 #41 0x64a34c05 in WebCore::JSMainThreadExecState::call (exec=0x6253f994, functionObject=..., callType=JSC::CallTypeJS, callData=..., thisValue=..., args=...) at ../../../../src/main/native/Source/WebCore/bindings/js/JSMainThreadExecState.h:56 #42 0x64a7e0cb in WebCore::ScheduledAction::executeFunctionInContext (this=0x524f9388, globalObject=0x6253f838, thisValue=..., context=0x62c58a50) at ../../../../src/main/native/Source/WebCore/bindings/js/ScheduledAction.cpp:111 #43 0x64a7e312 in WebCore::ScheduledAction::execute (this=0x524f9388, document=0x62c589f0) at ../../../../src/main/native/Source/WebCore/bindings/js/ScheduledAction.cpp:132 #44 0x64a7de62 in WebCore::ScheduledAction::execute (this=0x524f9388, context=0x62c58a50) at ../../../../src/main/native/Source/WebCore/bindings/js/ScheduledAction.cpp:80 #45 0x651930df in WebCore::DOMTimer::fired (this=0x442283f8) at ../../../../src/main/native/Source/WebCore/page/DOMTimer.cpp:140 #46 0x65360730 in WebCore::ThreadTimers::sharedTimerFiredInternal (this=0x70dd3a50) at ../../../../src/main/native/Source/WebCore/platform/ThreadTimers.cpp:129 #47 0x65360663 in WebCore::ThreadTimers::sharedTimerFired () at ../../../../src/main/native/Source/WebCore/platform/ThreadTimers.cpp:105 #48 0x65303abe in Java_com_sun_webkit_Timer_twkFireTimerEvent (env=0x6890552c, clazz=0x68aa00c0) at ../../../../src/main/native/Source/WebCore/platform/java/SharedTimerJava.cpp:63 ... ...
06-06-2014
We are sorry, but at this time we have no resources to work on WebView bugs for the 8u20 release. Unfortunately, we will have to defer them to 8u40.
23-05-2014
Leonid, have you been able to recreate this? See the code in comment - Apr, 30 2014 09:11 AM.
12-05-2014
Hi Again, I can confirm a crash also on a 64 bit Fedora 20, but still with 32 bit JDK 8u5. This time I used: (ulimit -v 1800000; java -Xmx1g -jar ...) I haven't managed to start a JVM instance using 64 bit JDK with limited virtual memory (using ulimit -v). Probably because JVM arranges internal sizing and addresses based on total memory reported by OS and not based on limits imposed by ulimit -v. Perhaps on a 2...3G physical system (or if 64 bit linux kernel was given some hint to only use 2...3G of RAM), the same crash could be observed even with 64 bit JDK.
12-05-2014
I don't think the firewall matters. What we have observed is that the crash seems more frequent when run on 32bit JDK using -Xmx1g -Xms1g. This way only approx. 1GB of RAM is left for non-heap process space. I suggest to experiment with different -Xmx values. In addition, it seems to happen more frequently on slower machines.
05-05-2014
So far I am not able to reproduce this crash on FX 8 or 8u20, either with 32-bit Windows or 64-bit Windows. I am running it behind our firewall using a proxy. I will try it outside the firewall to see if that matters.
01-05-2014
I am reopening this bug since there is a test case that reproduces the crash. It may be a duplicate of other already-opened bugs.
01-05-2014
Hi, We are getting hit by this exact crash in JDK 8 / JavaFX 8. Currently I can only confirm this for Windows 32 bit Oracle JDK and 64 bit Oracle JDK (tried also with 8u5 and 8u20 prerelease with same results), but I will test on other HW/OS platforms later and report back. The crash is not dependent on the pipeline choosen (tried with d3d,sw,j2d - crashes the same). Here's how to reproduce it: - conctruct a minimal WebView viewer (we tested with WebView embedded in JFXPanel in a JFrame window, because we use it this way in our app - as part of a Swing application, but it also crashes in pure JavaFX app) - load the following URL: http://octane-benchmark.googlecode.com/svn/latest/index.html - run the tests.... The crash happens on either the "pdf.js" or "zlib" test. Also try to up the heap size (-Xmx1g) especialy on 32 bit JDK. It seems to have some impact on the probability of crash. This is the test code we are using to provoke the crash (pure FX variant): public class WebKitInFxTest extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage stage) throws Exception { stage.setTitle("Octane Crash Test (pure FX)"); stage.setScene(new Scene( new Browser("http://octane-benchmark.googlecode.com/svn/latest/index.html"), 750, 500, Color.web("#666970") )); stage.show(); } static class Browser extends Region { final WebView wv = new WebView(); public Browser(String url) { wv.getEngine().load(url); getChildren().add(wv); } @Override protected void layoutChildren() { layoutInArea(wv, 0, 0, getWidth(), getHeight(), 0, HPos.CENTER, VPos.CENTER); } } } Regards, Peter
30-04-2014
Thanks for getting back to us.
27-03-2014
We could not wait with our deployment for this to be fixed, so we don't use javafx embedded browser any more. The crashes don't occur any more.
27-03-2014
We could consider fixing this for 7, however we don't have a repeatable case. Further we are not even sure that it is fixed in 8. We'll close this for now. Please reopen with a test case that shows the problem. If the bug is gone from 8, please let us know. Thanks!
26-03-2014
This may be a duplicate of RT-27803
20-12-2013
May be linked to RT-29693
17-12-2013
Marking as fixed in 7u45 as RT-33856 seems completely different.
31-10-2013
Meanwhile, I installed JDK 7u45 / FX 2.2.45 on my dev box and on 2 machines in the lab. On my dev box, I had a reproducible scenario which used to crash jvm. Not crashing any more. For the lab it's too early to say, since it's not reproducible. I'll keep you posted. Update 10/25/13: Unfortunately fails again: https://javafx-jira.kenai.com/browse/RT-33856
25-10-2013
I don't think so. Even I can't reporoduce it. In the lab, we have some 10 machines, it happens occasionally on one or two once a week or so. No indication of specific cause. My hope is, once we get the Java update everywhere, we don't see the crashes any more.
23-10-2013
Is there a way for me to reproduce? Are you just visiting some site when it crashes?
23-10-2013
Thanks for the immediate response. Yes, we run a specific version of JDK. The reason is, at the customer site, we don't have the freedom to upgrade as we wish. I could try to a newer version in the test lab and see how it goes. The problem is, I don't have a reproducible scenario. It just happens every now and then.
17-10-2013
You are running an old version of the JDK and JavaFX (7u17 / 2.2.7). Can you try it with JDK 7u45 / FX 2.2.45 and see if the bug still appears?
15-10-2013