Bug 166944 – ASSERT_NOT_REACHED in Heap::endMarking seen on EWS bots

• Status: NEW
• Component: JavaScriptCore

[Joseph Pecoraro]

Created attachment 298622 [details]
Crash Log

ASSERT_NOT_REACHED in Heap::endMarking seen on EWS bots

Saw this on EWS output on bug 166862 from yesterday (1/10/2017). That bug does not appear to be related in any way. Attached the full crash from the bot.

Unresolved visit races: 0x126ca2050(JSObject::visitButterfly)
SHOULD NEVER BE REACHED
/Volumes/Data/EWS/WebKit/Source/JavaScriptCore/heap/Heap.cpp(790) : void JSC::Heap::endMarking()
1   0x105627000 WTFCrash
2   0x104e8bcd5 JSC::Heap::endMarking()
3   0x104e8b466 JSC::Heap::markToFixpoint(double)
4   0x104e8e215 JSC::Heap::collectInThread()
5   0x104e9e179 JSC::Heap::Thread::work()
6   0x105634524 WTF::AutomaticThread::start(WTF::Locker<WTF::LockBase> const&)::$_0::operator()() const
7   0x1056342cd void std::__1::__invoke_void_return_wrapper<void>::__call<WTF::AutomaticThread::start(WTF::Locker<WTF::LockBase> const&)::$_0&>(WTF::AutomaticThread::start(WTF::Locker<WTF::LockBase> const&)::$_0&&&)
8   0x1056340bc std::__1::__function::__func<WTF::AutomaticThread::start(WTF::Locker<WTF::LockBase> const&)::$_0, std::__1::allocator<WTF::AutomaticThread::start(WTF::Locker<WTF::LockBase> const&)::$_0>, void ()>::operator()()
9   0x104c2b7ea std::__1::function<void ()>::operator()() const
10  0x1056a1ede WTF::threadEntryPoint(void*)
11  0x1056a3981 WTF::wtfThreadEntryPoint(void*)
12  0x7fff96cc599d _pthread_body
13  0x7fff96cc591a _pthread_body
14  0x7fff96cc3351 thread_start

Appears to be this assert:

void Heap::endMarking()
{
    if (!m_visitRaces.isEmpty()) {
        dataLog("Unresolved visit races: ", listDump(m_visitRaces), "\n");
        RELEASE_ASSERT_NOT_REACHED();
    }
    ...
}

[Joseph Pecoraro]

<rdar://problem/29688127>

[Mark Lam]

This can be caused by the issue found and explained in https://bugs.webkit.org/show_bug.cgi?id=166960.  Hence, this may be a dupe.

[Mark Lam]

Let's watch the bots now that the fix for https://bugs.webkit.org/show_bug.cgi?id=166960 has landed.  This issue is probably fixed now.