Bug 173846 – ASSERT(m_state == State::Active || m_state == State::Canceled) fails in AsyncStackTrace::didDispatchAsyncCall()

• Status: NEW
• Component: Web Inspector

[Daniel Bates]

MiniBrowser (WK1) crashed because the assertion ASSERT(m_state == State::Active || m_state == State::Canceled) failed in AsyncStackTrace::didDispatchAsyncCall(). I hit this assertion while having the inspector open, waiting until the page <http://www.newsweek.com/portland-stabbing-trump-responds-public-outcry-617076?spMailingID=1907309&spUserID=MzQ4OTUzNjk0MzcS1&spJobID=791102629&spReportId=NzkxMTAyNjI5S0> caused JavaScript error "Unhandled Promise Rejection: TypeError: null is not an object (evaluating 'a.className')", and then selecting this error, expanding it, and copying it to the clipboard.

#0	0x0000000111cce1e4 in ::WTFCrash() at /Volumes/.../OpenSource/Source/WTF/wtf/Assertions.cpp:293
#1	0x0000000110b5a6f4 in Inspector::AsyncStackTrace::didDispatchAsyncCall() at /Volumes/.../OpenSource/Source/JavaScriptCore/inspector/AsyncStackTrace.cpp:76
#2	0x0000000111541e9f in Inspector::InspectorDebuggerAgent::didDispatchAsyncCall() at /Volumes/.../OpenSource/Source/JavaScriptCore/inspector/agents/InspectorDebuggerAgent.cpp:305
#3	0x000000010569e445 in WebCore::InspectorInstrumentation::didFireTimerImpl(WebCore::InspectorInstrumentationCookie const&) at /Volumes/.../OpenSource/Source/WebCore/inspector/InspectorInstrumentation.cpp:469
#4	0x0000000104e52418 in WebCore::InspectorInstrumentation::didFireTimer(WebCore::InspectorInstrumentationCookie const&) at /Volumes/.../OpenSource/Source/WebCore/inspector/InspectorInstrumentation.h:752
#5	0x0000000104e52095 in WebCore::DOMTimer::fired() at /Volumes/.../OpenSource/Source/WebCore/page/DOMTimer.cpp:382
#6	0x00000001070ea9f4 in WebCore::ThreadTimers::sharedTimerFiredInternal() at /Volumes/.../OpenSource/Source/WebCore/platform/ThreadTimers.cpp:118
#7	0x00000001070eb161 in WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::$_0::operator()() const at /Volumes/.../OpenSource/Source/WebCore/platform/ThreadTimers.cpp:70
#8	0x00000001070eb119 in WTF::Function<void ()>::CallableWrapper<WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::$_0>::call() at /Volumes/.../OpenSource/WebKitBuild/Debug/usr/local/include/wtf/Function.h:102
#9	0x000000010464e14e in WTF::Function<void ()>::operator()() const at /Volumes/.../OpenSource/WebKitBuild/Debug/usr/local/include/wtf/Function.h:56
#10	0x00000001063cc925 in WebCore::MainThreadSharedTimer::fired() at /Volumes/.../OpenSource/Source/WebCore/platform/MainThreadSharedTimer.cpp:52
#11	0x00000001063cccb9 in WebCore::timerFired(__CFRunLoopTimer*, void*) at /Volumes/.../OpenSource/Source/WebCore/platform/cf/MainThreadSharedTimerCF.cpp:74
#12	0x00007fffbae2a2b4 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ ()
#13	0x00007fffbae29f72 in __CFRunLoopDoTimer ()
#14	0x00007fffbae29aea in __CFRunLoopDoTimers ()
#15	0x00007fffbae213f4 in __CFRunLoopRun ()
#16	0x00007fffbae20959 in CFRunLoopRunSpecific ()
#17	0x00007fffba16f97b in RunCurrentEventLoopInMode ()
#18	0x00007fffba16f627 in ReceiveNextEventCommon ()
#19	0x00007fffba16f49c in _BlockUntilNextEventMatchingListInModeWithFilter ()
#20	0x00007fffb84551eb in _DPSNextEvent ()
#21	0x00007fffb8bdb53a in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] ()
#22	0x00007fffb8449d75 in -[NSApplication run] ()
#23	0x00007fffb8419149 in NSApplicationMain ()
#24	0x0000000100008f39 in main at /Volumes/.../OpenSource/Tools/MiniBrowser/mac/main.m:32
#25	0x00007fffe22b111d in start ()

[Daniel Bates]

Briefly looking at the inspector code, Inspector::AsyncStackTrace::didDispatchAsyncCall() is called so long as we have an inspector debugger agent regardless of whether AsyncStackTrace::willDispatchAsyncCall() was called on the pending async call.

[Matt Baker]

(In reply to Daniel Bates from comment #1)
> Briefly looking at the inspector code,
> Inspector::AsyncStackTrace::didDispatchAsyncCall() is called so long as we
> have an inspector debugger agent regardless of whether
> AsyncStackTrace::willDispatchAsyncCall() was called on the pending async
> call.

Since it is called on the trace identifier by `m_currentAsyncCallIdentifier`, which is set during willDispatchAsyncCall(), it shouldn't be possible for didDispatchAsyncCall() to be called in isolation.

Will investigate.