[Webkit-unassigned] [Bug 153819] New: [JavaScriptCore] JavaScriptCore is crashed when PARRELLEL GC is enabled.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Feb 2 21:20:51 PST 2016


https://bugs.webkit.org/show_bug.cgi?id=153819

            Bug ID: 153819
           Summary: [JavaScriptCore] JavaScriptCore is crashed when
                    PARRELLEL GC is enabled.
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Critical
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: xinchao.peng at samsung.com

Hello, GC experts.

Recently I met a GC crash when PARRALLEL GC is enabled. Crash is like:

#0  0x00007ffff72a1671 in isJSString (this=0x7fffeaec0cd8) at /home/oszi/WebKit/Source/JavaScriptCore/runtime/JSString.h:501
#1  visitChildren (this=0x7fffeaec0cd8) at /home/oszi/WebKit/Source/JavaScriptCore/heap/MarkStack.cpp:351
#2  JSC::SlotVisitor::drain (this=0x7fffeaec0cd8) at /home/oszi/WebKit/Source/JavaScriptCore/heap/MarkStack.cpp:405
#3  0x00007ffff72a19e4 in JSC::SlotVisitor::drainFromShared (this=0x7fffeaec0cd8, sharedDrainMode=JSC::SlotVisitor::MasterDrain) at /home/oszi/WebKit/Source/JavaScriptCore/heap/MarkStack.cpp:498
#4  0x00007ffff729dd38 in JSC::Heap::markRoots (this=0x7fffeaec0050, fullGC=<value optimized out>) at /home/oszi/WebKit/Source/JavaScriptCore/heap/Heap.cpp:555
#5  0x00007ffff729df8b in JSC::Heap::collect (this=0x7fffeaec0050, sweepToggle=JSC::Heap::DoNotSweep) at /home/oszi/WebKit/Source/JavaScriptCore/heap/Heap.cpp:717
#6  0x00007ffff72a410c in JSC::MarkedAllocator::allocateSlowCase (this=0x7fffeaec0158) at /home/oszi/WebKit/Source/JavaScriptCore/heap/MarkedAllocator.cpp:75
#7  0x00007ffff72e84ba in JSC::MarkedAllocator::allocate (exec=<value optimized out>) at /home/oszi/WebKit/Source/JavaScriptCore/heap/MarkedAllocator.h:77
#8  JSC::MarkedSpace::allocateWithDestructor (exec=<value optimized out>) at /home/oszi/WebKit/Source/JavaScriptCore/heap/MarkedSpace.h:191
#9  JSC::Heap::allocateWithDestructor (exec=<value optimized out>) at /home/oszi/WebKit/Source/JavaScriptCore/heap/Heap.h:362
#10 allocateCell<JSC::JSFinalObject> (exec=<value optimized out>) at /home/oszi/WebKit/Source/JavaScriptCore/runtime/JSCell.h:340
#11 JSC::JSFinalObject::create (exec=<value optimized out>) at /home/oszi/WebKit/Source/JavaScriptCore/runtime/JSObject.h:439
#12 constructEmptyObject (exec=<value optimized out>) at /home/oszi/WebKit/Source/JavaScriptCore/runtime/JSObject.h:515
#13 constructEmptyObject (exec=<value optimized out>) at /home/oszi/WebKit/Source/JavaScriptCore/runtime/JSGlobalObject.h:431
#14 constructEmptyObject (exec=<value optimized out>) at /home/oszi/WebKit/Source/JavaScriptCore/runtime/JSGlobalObject.h:436
#15 operationNewObject (exec=<value optimized out>) at /home/oszi/WebKit/Source/JavaScriptCore/dfg/DFGOperations.cpp:305
#16 0x00007fffaaf8880d in ?? ()
#17 0x0000000000000000 in ?? ()


I checked the code of JSCore GC.

void SlotVisitor::drain()
{
    StackStats::probe();
    ASSERT(m_isInParallelMode);

#if ENABLE(PARALLEL_GC)
    if (Options::numberOfGCMarkers() > 1) {
        while (!m_stack.isEmpty()) {
            m_stack.refill();
            for (unsigned countdown = Options::minimumNumberOfScansBetweenRebalance(); m_stack.canRemoveLast() && countdown--;)
                visitChildren(*this, m_stack.removeLast());
            donateKnownParallel();
        }

        mergeOpaqueRootsIfNecessary();
        return;
    }
#endif

    while (!m_stack.isEmpty()) {
        m_stack.refill();
        while (m_stack.canRemoveLast())
            visitChildren(*this, m_stack.removeLast());
    }
}

Why is m_shared.m_markingLock not added before m_stack.refill() and m_stack.removeLast(), just like inside the function void SlotVisitor::donateKnownParallel() ?

It seems that m_stack is operated unsafely when PARRELLEL GC is enabled.

What do you think?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160203/35c3aa67/attachment-0001.html>


More information about the webkit-unassigned mailing list