Bug 173846
| Summary: | ASSERT(m_state == State::Active || m_state == State::Canceled) fails in AsyncStackTrace::didDispatchAsyncCall() | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Daniel Bates <dbates> |
| Component: | Web Inspector | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | inspector-bugzilla-changes, joepeck, mattbaker |
| Priority: | P2 | ||
| Version: | WebKit Local Build | ||
| Hardware: | Mac | ||
| OS: | macOS 10.13 | ||
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 ()
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
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.