Bug 108223 – [Mac] Flaky crash in SliderThumbElement::defaultEventHandler on fast/forms/range/slider-delete-while-dragging-thumb.html

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: New Bugs

[Ryosuke Niwa]

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

[Jessie Berlin]

Possibly related to http://trac.webkit.org/changeset/141119, which was introduced 5 hours ago?

[Alexis Menard (darktears)]

(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.

[Alexis Menard (darktears)]

(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?

[Jessie Berlin]

<rdar://problem/13114895>

[Dimitri Glazkov (Google)]

Elliott said he's digging into this.

[Alexis Menard (darktears)]

(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

[Alexis Menard (darktears)]

(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.

[Simon Fraser (smfr)]

Marked as flakey crash in http://trac.webkit.org/changeset/146217

[Elliott Sprehn]

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.

[Alexey Proskuryakov]

This doesn't happen on bots any more, I'll try unskipping.