[Webkit-unassigned] [Bug 200863] Crash in JSC::SlotVisitor::visitChildren

[bugzilla-daemon at webkit.org]

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

--- Comment #29 from Krzysztof Konopko <kris at youview.com> ---
(In reply to Michael Catanzaro from comment #28)
> (In reply to Mark Lam from comment #25)
> > However, JSSymbolTableObject::m_symbolTable is a WriteBarrier<SymbolTable>,
> > and all WriteBarriers have a default constructor:
> > ```
> >     WriteBarrier()
> >     {
> >         this->setWithoutWriteBarrier(nullptr);
> >     }
> > ```
> > ... which implies that Valgrind is wrong here.
> 
> That just means that my assumption that m_cell is never initialized was
> wrong. A bug in WebKit is drastically more likely than a bug in valgrind. So
> if the m_cell is initially initialized, then it must be overwritten with
> uninitialized memory from someplace else later on. valgrind should be able
> to pinpoint where it's coming from, but not by default: you need to use
> --track-origins flag (which is slow!) to show that. There's a good chance
> that will give us the remaining info we need to fix this. Hopefully.
> 

Well, I was running with `--track-origins` pretty much early on.  I just thought I've already presented the results of this option.  Apparently not, my bad!

Anyway, here's another example I still have lingering in one of the terminals, with the origin pointing to something on the stack:

==116== Use of uninitialised value of size 8
==116==    at 0x313B069: JSC::MarkedBlock::aboutToMarkSlow(unsigned int) (MarkedBlock.cpp:233)
==116==    by 0x1F191A1: JSC::MarkedBlock::aboutToMark(unsigned int) (MarkedBlock.h:573)
==116==    by 0x315BB5A: JSC::Heap::testAndSetMarked(unsigned int, void const*) (HeapInlines.h:86)
==116==    by 0x31579D6: JSC::SlotVisitor::appendJSCellOrAuxiliary(JSC::HeapCell*) (SlotVisitor.cpp:199)
==116==    by 0x3157366: JSC::SlotVisitor::append(JSC::ConservativeRoots const&) (SlotVisitor.cpp:134)
==116==    by 0x30B7E57: auto JSC::Heap::addCoreConstraints()::{lambda(auto:1&)#2}::operator()<JSC::SlotVisitor>(JSC::SlotVisitor&) (Heap.cpp:2788)
==116==    by 0x30B8063: WTF::Detail::CallableWrapper<JSC::Heap::addCoreConstraints()::{lambda(auto:1&)#2}, void, JSC::SlotVisitor&>::call(JSC::SlotVisitor&) (Function.h:53)
==116==    by 0x315CDEE: WTF::Function<void (JSC::SlotVisitor&)>::operator()(JSC::SlotVisitor&) const (Function.h:82)
==116==    by 0x315C0B8: JSC::MarkingConstraintExecutorPair::execute(JSC::SlotVisitor&) (MarkingConstraintExecutorPair.h:45)
==116==    by 0x315CE4A: void JSC::SimpleMarkingConstraint::executeImplImpl<JSC::SlotVisitor>(JSC::SlotVisitor&) (SimpleMarkingConstraint.cpp:48)
==116==    by 0x3156D42: JSC::SimpleMarkingConstraint::executeImpl(JSC::SlotVisitor&) (SimpleMarkingConstraint.cpp:52)
==116==    by 0x313E948: JSC::MarkingConstraint::execute(JSC::SlotVisitor&) (MarkingConstraint.cpp:58)
==116==  Uninitialised value was created by a stack allocation
==116==    at 0x32D2817: JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (Interpreter.cpp:1016)

I looked there but honestly couldn't figure out what could go wrong here.  This is pretty recent WebKit mainline branch on x86_64.

Note that it's a Valgring's limitation when it points at a function in case of the stack origin.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20221118/d59562b2/attachment-0001.htm>