108223 2013-01-29 13:28:33 -0800 [Mac] Flaky crash in SliderThumbElement::defaultEventHandler on fast/forms/range/slider-delete-while-dragging-thumb.html 2014-12-09 22:40:28 -0800 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) Unspecified Unspecified RESOLVED WORKSFORME InRadar P2 Normal --- 1 rniwa esprehn dglazkov esprehn jberlin jchaffraix jonlee menard simon.fraser webkit-bug-importer oldest_to_newest 819280 0 rniwa 2013-01-29 13:28:33 -0800 e.g. http://build.webkit.org/results/Apple%20MountainLion%20Release%20WK1%20(Tests)/r141136%20(6255)/results.html CRASHING TEST: fast/forms/range/slider-delete-while-dragging-thumb.html Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.WebCore 0x000000010ebb074a WebCore::SliderThumbElement::defaultEventHandler(WebCore::Event*) + 42 (SliderThumbElement.cpp:404) 1 com.apple.WebCore 0x000000010e33b492 WebCore::EventDispatcher::dispatchEventPostProcess(WTF::PassRefPtr<WebCore::Event>, void*) + 306 (PassRefPtr.h:77) 2 com.apple.WebCore 0x000000010e33b25f WebCore::EventDispatcher::dispatchEvent(WTF::PassRefPtr<WebCore::Event>) + 1343 (PassRefPtr.h:68) 3 com.apple.WebCore 0x000000010e950773 WebCore::MouseEventDispatchMediator::dispatchEvent(WebCore::EventDispatcher*) const + 323 (PassRefPtr.h:68) 4 com.apple.WebCore 0x000000010e3397c0 WebCore::EventDispatcher::dispatchEvent(WebCore::Node*, WTF::PassRefPtr<WebCore::EventDispatchMediator>) + 160 (EventDispatcher.cpp:135) 5 com.apple.WebCore 0x000000010e964b95 WebCore::Node::dispatchMouseEvent(WebCore::PlatformMouseEvent const&, WTF::AtomicString const&, int, WebCore::Node*) + 133 (Node.cpp:2381) 6 com.apple.WebCore 0x000000010e343f0b WebCore::EventHandler::updateMouseEventTargetNode(WebCore::Node*, WebCore::PlatformMouseEvent const&, bool) + 1595 (RefPtr.h:70) 7 com.apple.WebCore 0x000000010e342a3c WebCore::EventHandler::dispatchMouseEvent(WTF::AtomicString const&, WebCore::Node*, bool, int, WebCore::PlatformMouseEvent const&, bool) + 76 (RefPtr.h:70) 8 com.apple.WebCore 0x000000010e342632 WebCore::EventHandler::handleMousePressEvent(WebCore::PlatformMouseEvent const&) + 1426 (EventHandler.cpp:1508) 9 com.apple.WebCore 0x000000010e34a279 WebCore::EventHandler::mouseDown(NSEvent*) + 89 (EventHandlerMac.mm:474) 10 com.apple.WebKit 0x000000010dd769d9 -[WebHTMLView mouseDown:] + 393 (WebHTMLView.mm:3595) 11 DumpRenderTree 0x000000010d62de5e -[EventSendingController mouseDown:withModifiers:] + 423 (EventSendingController.mm:357) 12 com.apple.CoreFoundation 0x00007fff939a263c __invoking___ + 140 13 com.apple.CoreFoundation 0x00007fff939a24d7 -[NSInvocation invoke] + 263 14 com.apple.WebCore 0x000000010e974252 JSC::Bindings::ObjcInstance::invokeObjcMethod(JSC::ExecState*, JSC::Bindings::ObjcMethod*) + 1042 (objc_instance.mm:323) 15 com.apple.WebCore 0x000000010e973d9d JSC::Bindings::ObjcInstance::invokeMethod(JSC::ExecState*, JSC::RuntimeMethod*) + 93 (objc_instance.mm:232) 16 com.apple.WebCore 0x000000010eb57560 JSC::callRuntimeMethod(JSC::ExecState*) + 240 (runtime_method.cpp:115) 17 com.apple.JavaScriptCore 0x000000010d923473 JSC::LLInt::setUpCall(JSC::ExecState*, JSC::Instruction*, JSC::CodeSpecializationKind, JSC::JSValue, JSC::LLIntCallLinkInfo*) + 211 (LLIntSlowPaths.cpp:1364) 18 com.apple.JavaScriptCore 0x000000010d927bb0 llint_op_call + 169 19 com.apple.JavaScriptCore 0x000000010d85ddf3 JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 611 (JSCJSValueInlines.h:363) 20 com.apple.JavaScriptCore 0x000000010d769fe5 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 69 (CallData.cpp:40) 21 com.apple.WebCore 0x000000010e5da5cf WebCore::JSMainThreadExecState::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 143 (JSMainThreadExecState.h:56) 22 com.apple.WebCore 0x000000010eb5ac61 WebCore::ScheduledAction::executeFunctionInContext(JSC::JSGlobalObject*, JSC::JSValue, WebCore::ScriptExecutionContext*) + 481 (ScheduledAction.cpp:112) 23 com.apple.WebCore 0x000000010eb5a8fc WebCore::ScheduledAction::execute(WebCore::Document*) + 156 (ScheduledAction.cpp:134) 24 com.apple.WebCore 0x000000010e2eced4 WebCore::DOMTimer::fired() + 388 (InspectorInstrumentation.h:284) 25 com.apple.WebCore 0x000000010ed20a8f WebCore::ThreadTimers::sharedTimerFiredInternal() + 159 (ThreadTimers.cpp:119) 26 com.apple.WebCore 0x000000010eba9e23 WebCore::timerFired(__CFRunLoopTimer*, void*) + 51 (SharedTimerMac.mm:167) 27 com.apple.CoreFoundation 0x00007fff9396bda4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20 28 com.apple.CoreFoundation 0x00007fff9396b8bd __CFRunLoopDoTimer + 557 29 com.apple.CoreFoundation 0x00007fff93951099 __CFRunLoopRun + 1513 819287 1 jberlin 2013-01-29 13:33:55 -0800 Possibly related to http://trac.webkit.org/changeset/141119, which was introduced 5 hours ago? 820023 2 menard 2013-01-30 03:02:08 -0800 (In reply to comment #1) > Possibly related to http://trac.webkit.org/changeset/141119, which was introduced 5 hours ago? It is really unlikely that it's this change. The change concerns only transition DOM events and more specifically related to DOM events for generated contents. From the backtrace it seems that it crashes in the handler of the slider. Maybe running the test in the browser with the debugger attached and pressing refresh could catch it so you can get more information. 820044 3 menard 2013-01-30 03:34:34 -0800 (In reply to comment #2) > (In reply to comment #1) > > Possibly related to http://trac.webkit.org/changeset/141119, which was introduced 5 hours ago? > > It is really unlikely that it's this change. The change concerns only transition DOM events and more specifically related to DOM events for generated contents. > > From the backtrace it seems that it crashes in the handler of the slider. Maybe running the test in the browser with the debugger attached and pressing refresh could catch it so you can get more information. You can modify the test case and run it in the MiniBrowser and you can reproduce the crash. https://gist.github.com/4672658 and press down the mouse on the slider and wait. It crashes in HTMLInputElement* SliderThumbElement::hostInput() const { // Only HTMLInputElement creates SliderThumbElement instances as its shadow nodes. // So, shadowHost() must be an HTMLInputElement. return shadowHost()->toInputElement(); } shadowHost() seems to be null. We could "fix" it by checking the return value of shadowHost() but I can't tell if that's right or not. Dimitry? 820244 4 jberlin 2013-01-30 08:57:31 -0800 <rdar://problem/13114895> 820278 5 dglazkov 2013-01-30 09:51:15 -0800 Elliott said he's digging into this. 822045 6 menard 2013-01-31 15:36:29 -0800 (In reply to comment #5) > Elliott said he's digging into this. we should probably mark it as flaky in the meantime. It brings problem in the cq https://bugs.webkit.org/show_bug.cgi?id=108216 822722 7 menard 2013-02-01 06:37:41 -0800 (In reply to comment #6) > (In reply to comment #5) > > Elliott said he's digging into this. > > we should probably mark it as flaky in the meantime. It brings problem in the cq > > https://bugs.webkit.org/show_bug.cgi?id=108216 Sorry It was unrelated. 858431 8 simon.fraser 2013-03-19 10:29:30 -0700 Marked as flakey crash in http://trac.webkit.org/changeset/146217 860110 9 esprehn 2013-03-21 00:38:38 -0700 I'll see if I cycle back around on this soon. I think the issue is that EventHandler has a reference to this shadow node with m_capturingMouseEventsNode (or a related property) and then the input is torn down but the EventHandler isn't cleaned up. That's the only way I can figure that shadowHost() can be 0. I think we might want to reconsider how we implement form controls though. In JS when you're using Shadow DOM we have lots of protections and a restricted life cycle. Inside the C++ widgets we make a lot of assumptions about the structure of the widget which is dangerous. 1054044 10 ap 2014-12-09 22:40:28 -0800 This doesn't happen on bots any more, I'll try unskipping.