Bug 73886 – REGRESSION(r101863-r102042): Assertion hit: m_verifier.isSafeToUse() in RefCountedBase::ref in FunctionCodeBlock

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Ryosuke Niwa]

I've been browsing on r102042 and I've been repeatedly hitting the following assertion:

class RefCountedBase {
public:
    void ref()
    {
#ifndef NDEBUG
        // Start thread verification as soon as the ref count gets to 2. This
        // heuristic reflects the fact that items are often created on one thread
        // and then given to another thread to be used.
        // FIXME: Make this restriction tigher. Especially as we move to more
        // common methods for sharing items across threads like CrossThreadCopier.h
        // We should be able to add a "detachFromThread" method to make this explicit.
        if (m_refCount == 1)
            m_verifier.setShared(true);
#endif
        // If this assert fires, it either indicates a thread safety issue or
        // that the verification needs to change. See ThreadRestrictionVerifier for
        // the different modes.
        ASSERT(m_verifier.isSafeToUse()); // < this one!

#0	0x1000c940a in WTF::RefCountedBase::ref at RefCounted.h:53
#1	0x1000dd65c in JSC::FunctionCodeBlock::FunctionCodeBlock at CodeBlock.h:1361
#2	0x1000d5a67 in JSC::FunctionExecutable::produceCodeBlockFor at Executable.cpp:475
#3	0x1000d6aea in JSC::FunctionExecutable::compileForCallInternal at Executable.cpp:516
#4	0x1000d6ffd in JSC::FunctionExecutable::compileOptimizedForCall at Executable.cpp:447
#5	0x1000780b3 in JSC::FunctionExecutable::compileOptimizedFor at Executable.h:573
#6	0x1000657cc in JSC::FunctionCodeBlock::compileOptimized at CodeBlock.cpp:2146
#7	0x10011e8b8 in cti_optimize_from_ret at JITStubs.cpp:2059
#8	0x100117386 in ctiOpThrowNotCaught at Instruction.h:81
#9	0x1000f41a0 in JSC::JITCode::execute at JITCode.h:115
#10	0x1000ea0ca in JSC::Interpreter::executeCall at Interpreter.cpp:1075
#11	0x100062787 in JSC::call at CallData.cpp:39
#12	0x10016238e in JSObjectCallAsFunction at JSObjectRef.cpp:443

[Ryosuke Niwa]

JSC changes in the regression window: http://trac.webkit.org/log/trunk/Source/JavaScriptCore?action=stop_on_copy&mode=stop_on_copy&rev=102042&stop_rev=101863&limit=100&verbose=on

[Geoffrey Garen]

Can you attach a full set of backtraces for all threads?

My guess is that the ASSERT (i.e., the verifier) needs to change, but I'd like to make sure.

[Ryosuke Niwa]

(In reply to comment #2)
> Can you attach a full set of backtraces for all threads?
> 
> My guess is that the ASSERT (i.e., the verifier) needs to change, but I'd like to make sure.

Hm... I'm using WebKit1 so this is the "only" thread. Is there any information you're looking for?

[Ryosuke Niwa]

Some stack traces. FYI, it's super easy to reproduce if you go to facebook and spend even like 1-2 minutes click on different places.

Safari: SafeBrowsingManager:
#0	0x1000c940a in WTF::RefCountedBase::ref at RefCounted.h:53
#1	0x1000dd65c in JSC::FunctionCodeBlock::FunctionCodeBlock at CodeBlock.h:1361
#2	0x1000d5a67 in JSC::FunctionExecutable::produceCodeBlockFor at Executable.cpp:475
#3	0x1000d6aea in JSC::FunctionExecutable::compileForCallInternal at Executable.cpp:516
#4	0x1000d6ffd in JSC::FunctionExecutable::compileOptimizedForCall at Executable.cpp:447
#5	0x1000780b3 in JSC::FunctionExecutable::compileOptimizedFor at Executable.h:573
#6	0x1000657cc in JSC::FunctionCodeBlock::compileOptimized at CodeBlock.cpp:2146
#7	0x10011e8b8 in cti_optimize_from_ret at JITStubs.cpp:2059
#8	0x100117386 in ctiOpThrowNotCaught at Instruction.h:81
#9	0x1000f41a0 in JSC::JITCode::execute at JITCode.h:115
#10	0x1000ea0ca in JSC::Interpreter::executeCall at Interpreter.cpp:1075
#11	0x100062787 in JSC::call at CallData.cpp:39
#12	0x10016238e in JSObjectCallAsFunction at JSObjectRef.cpp:443

JavaScriptCore::Marking
#0	0x7fff88483a6a in __semwait_signal
#1	0x7fff88487881 in _pthread_cond_wait
#2	0x100234f4d in WTF::ThreadCondition::wait at ThreadingPthreads.cpp:372
#3	0x100268245 in JSC::SlotVisitor::drainFromShared at MarkStack.cpp:423
#4	0x1002686cc in JSC::MarkStackThreadSharedData::markingThreadMain at MarkStack.cpp:224
#5	0x100268711 in JSC::MarkStackThreadSharedData::markingThreadStartFunc at MarkStack.cpp:229
#6	0x100234dc2 in WTF::threadEntryPoint at Threading.cpp:67
#7	0x7fff88481fd6 in _pthread_start
#8	0x7fff88481e89 in thread_start

JavaScriptCore::Marking
#0	0x7fff88483a6a in __semwait_signal
#1	0x7fff88487881 in _pthread_cond_wait
#2	0x100234f4d in WTF::ThreadCondition::wait at ThreadingPthreads.cpp:372
#3	0x100268245 in JSC::SlotVisitor::drainFromShared at MarkStack.cpp:423
#4	0x1002686cc in JSC::MarkStackThreadSharedData::markingThreadMain at MarkStack.cpp:224
#5	0x100268711 in JSC::MarkStackThreadSharedData::markingThreadStartFunc at MarkStack.cpp:229
#6	0x100234dc2 in WTF::threadEntryPoint at Threading.cpp:67
#7	0x7fff88481fd6 in _pthread_start
#8	0x7fff88481e89 in thread_start

JavaScriptCore::Marking
#0	0x7fff88483a6a in __semwait_signal
#1	0x7fff88487881 in _pthread_cond_wait
#2	0x100234f4d in WTF::ThreadCondition::wait at ThreadingPthreads.cpp:372
#3	0x100268245 in JSC::SlotVisitor::drainFromShared at MarkStack.cpp:423
#4	0x1002686cc in JSC::MarkStackThreadSharedData::markingThreadMain at MarkStack.cpp:224
#5	0x100268711 in JSC::MarkStackThreadSharedData::markingThreadStartFunc at MarkStack.cpp:229
#6	0x100234dc2 in WTF::threadEntryPoint at Threading.cpp:67
#7	0x7fff88481fd6 in _pthread_start
#8	0x7fff88481e89 in thread_start

JavaScriptCore::BlockFree
#0	0x7fff88483a6a in __semwait_signal
#1	0x7fff88487881 in _pthread_cond_wait
#2	0x100235047 in WTF::ThreadCondition::timedWait at ThreadingPthreads.cpp:393
#3	0x10026f0a3 in JSC::Heap::waitForRelativeTimeWhileHoldingLock at Heap.cpp:391
#4	0x10026f0d9 in JSC::Heap::waitForRelativeTime at Heap.cpp:401
#5	0x10026f106 in JSC::Heap::blockFreeingThreadMain at Heap.cpp:415
#6	0x10026f239 in JSC::Heap::blockFreeingThreadStartFunc at Heap.cpp:406
#7	0x100234dc2 in WTF::threadEntryPoint at Threading.cpp:67
#8	0x7fff88481fd6 in _pthread_start
#9	0x7fff88481e89 in thread_start

Safari: SnapshotStore
#0	0x7fff88483a6a in __semwait_signal
#1	0x7fff88487881 in _pthread_cond_wait
#2	0x100234f4d in WTF::ThreadCondition::wait at ThreadingPthreads.cpp:372
#3	0x100234fde in WTF::ThreadCondition::timedWait at ThreadingPthreads.cpp:382
#4	0x7fff8729b949 in Safari::MessageQueue<WTF::RefPtr<Safari::SnapshotStore::DiskAccessMessage> >::waitForMessageFilteredWithTimeout<bool ()(WTF::RefPtr<Safari::SnapshotStore::DiskAccessMessage>&)>
#5	0x7fff87299d49 in Safari::SnapshotStore::diskAccessThreadBody
#6	0x7fff8729a503 in Safari::SnapshotStore::diskAccessThreadCallback
#7	0x100234dc2 in WTF::threadEntryPoint at Threading.cpp:67
#8	0x7fff88481fd6 in _pthread_start
#9	0x7fff88481e89 in thread_start

[Ryosuke Niwa]

com.apple.main-thread:
#0	0x1025dbefa in WebCore::JSNode::getOwnPropertySlot at JSNode.h:81
#1	0x1026cb777 in JSC::getStaticValueSlot<WebCore::JSElement, WebCore::JSNode> at Lookup.h:346
#2	0x1026cb8e7 in WebCore::JSElement::getOwnPropertySlot at JSElement.h:69
#3	0x1027254d3 in JSC::getStaticValueSlot<WebCore::JSHTMLElement, WebCore::JSElement> at Lookup.h:346
#4	0x10272485f in WebCore::JSHTMLElement::getOwnPropertySlot at JSHTMLElement.cpp:213
#5	0x10271e7c1 in JSC::getStaticValueSlot<WebCore::JSHTMLDivElement, WebCore::JSHTMLElement> at Lookup.h:346
#6	0x10271dc6d in WebCore::JSHTMLDivElement::getOwnPropertySlot at JSHTMLDivElement.cpp:148
#7	0x1000f46c8 in JSC::JSCell::fastGetOwnPropertySlot at JSObject.h:562
#8	0x1000f4889 in JSC::JSValue::get at JSObject.h:796
#9	0x1000b06e4 in operationGetById at DFGOperations.cpp:338
#10	0x56fc8d9b986a in ??
#11	0x1000f41a0 in JSC::JITCode::execute at JITCode.h:115
#12	0x1000ea0ca in JSC::Interpreter::executeCall at Interpreter.cpp:1075
#13	0x100062787 in JSC::call at CallData.cpp:39
#14	0x1026045dc in WebCore::JSMainThreadExecState::call at JSMainThreadExecState.h:52
#15	0x1026def8d in WebCore::JSEventListener::handleEvent at JSEventListener.cpp:124
#16	0x10231651a in WebCore::EventTarget::fireEventListeners at EventTarget.cpp:228
#17	0x102316a60 in WebCore::EventTarget::fireEventListeners at EventTarget.cpp:197
#18	0x102a44b61 in WebCore::Node::handleLocalEvents at Node.cpp:2842
#19	0x1022f80cc in WebCore::EventContext::handleLocalEvents at EventContext.cpp:48
#20	0x1022f9862 in WebCore::EventDispatcher::dispatchEvent at EventDispatcher.cpp:329
#21	0x102a30729 in WebCore::MouseEventDispatchMediator::dispatchEvent at MouseEvent.cpp:207
#22	0x1022f8b17 in WebCore::EventDispatcher::dispatchEvent at EventDispatcher.cpp:55
#23	0x102a44777 in WebCore::Node::dispatchMouseEvent at Node.cpp:2904
#24	0x102302c7d in WebCore::EventHandler::updateMouseEventTargetNode at EventHandler.cpp:2050
#25	0x102302dc8 in WebCore::EventHandler::dispatchMouseEvent at EventHandler.cpp:2067
#26	0x102305228 in WebCore::EventHandler::handleMouseMoveEvent at EventHandler.cpp:1675
#27	0x1023052de in WebCore::EventHandler::mouseMoved at EventHandler.cpp:1560
#28	0x10230b2fd in WebCore::EventHandler::mouseMoved at EventHandlerMac.mm:595
#29	0x100bfacf2 in -[WebHTMLView(WebPrivate) _updateMouseoverWithEvent:] at WebHTMLView.mm:1621
#30	0x100be3eaf in -[WebHTMLView mouseMovedNotification:] at WebHTMLView.mm:3711

[Geoffrey Garen]

It looks like the SafeBrowsingManager thread backtrace got truncated. Anyway, I think the right solution is to disable verification (deprecatedTurnOffVerifier). Verification is incorrect for all JavaScriptCore objects, since JavaScriptCore objects allow use on multiple threads.

[David Levin]

Agreed with Geoff, just like this:
http://trac.webkit.org/changeset/85233/trunk/Source/JavaScriptCore/parser/SourceProvider.h

for FunctionCodeBlock

[Ryosuke Niwa]

Apparently this assertion hits on r101863 as well.

[David Levin]

Created attachment 118646 [details]
Patch

[WebKit Review Bot]

Comment on attachment 118646 [details]
Patch

Clearing flags on attachment: 118646

Committed r102508: <http://trac.webkit.org/changeset/102508>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.