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

[bugzilla-daemon at webkit.org]

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

--- Comment #33 from Michael Catanzaro <mcatanzaro at gnome.org> ---
(In reply to Krzysztof Konopko from comment #31)
> Created attachment 463599 [details]
> Valgrind output when running JS-only test with `jsc`

Wow, looks like you've just found a lot of problems. :S We should endeavor to keep our valgrind output clean; otherwise, false positives may cause serious confusion when handling bug reports, e.g. see comment 10 in bug #182272 if you have permission to view it, where I incorrectly decided that a bunch of distinct security bugs were all duplicates of each other because the SUPPRESS_ASAN annotation was broken.

I notice the majority of these somehow involve JSC::ConservativeRoots. Does this code intentionally make branching decisions based on uninitialized values? Because that is what is currently happening, in a bunch of different places. But it looks like a human has assessed this and decided that it is OK, because look:

template<typename MarkHook>
SUPPRESS_ASAN
void ConservativeRoots::genericAddSpan(void* begin, void* end, MarkHook& markHook)

it says SUPPRESS_ASAN here. I think we need to (a) understand why this code is OK, (b) figure out how to avoid triggering valgrind by altering behavior using RUNNING_ON_VALGRIND from bmalloc/valgrind.h. We cannot simply tell valgrind to ignore problems that go via this function like we can with asan. (OK, we *can* by using suppression files, but the design of those is pretty broken, so nobody does.) Instead, we can detect valgrind with RUNNING_ON_VALGRIND, then vary behavior somehow to avoid the normally-intentional use of uninitialized memory. But doing that requires clearly understanding what the code is doing, so I won't be much help there....

Anyway, back to the original bug:

==125== Use of uninitialised value of size 8
==125==    at 0x1EF5EB8: JSC::WriteBarrierBase<JSC::JSGlobalObject, WTF::RawPtrTraits<JSC::JSGlobalObject> >::cell() const (WriteBarrier.h:153)
==125==    by 0x1EE9EC6: JSC::WriteBarrierBase<JSC::JSGlobalObject, WTF::RawPtrTraits<JSC::JSGlobalObject> >::get() const (WriteBarrier.h:101)
==125==    by 0x24FA88D: void JSC::SlotVisitor::append<JSC::JSGlobalObject, WTF::RawPtrTraits<JSC::JSGlobalObject> >(JSC::WriteBarrierBase<JSC::JSGlobalObject, WTF::RawPtrTraits<JSC::JSGlobalObject> > const&) (SlotVisitorInlines.h:110)
==125==    by 0x3ABFAAA: void JSC::Structure::visitChildrenImpl<JSC::SlotVisitor>(JSC::JSCell*, JSC::SlotVisitor&) (Structure.cpp:1275)
==125==    by 0x3AB33B0: JSC::Structure::visitChildren(JSC::JSCell*, JSC::SlotVisitor&) (Structure.cpp:1303)
==125==    by 0x315BA02: JSC::MethodTable::visitChildren(JSC::JSCell*, JSC::SlotVisitor&) const (ClassInfo.h:115)
==125==    by 0x315C654: JSC::SlotVisitor::visitChildren(JSC::JSCell const*) (SlotVisitor.cpp:394)
==125==    by 0x31580CB: JSC::SlotVisitor::drain(WTF::MonotonicTime)::{lambda(JSC::MarkStackArray&)#1}::operator()(JSC::MarkStackArray&) const (SlotVisitor.cpp:504)
==125==    by 0x315B150: WTF::IterationStatus JSC::SlotVisitor::forEachMarkStack<JSC::SlotVisitor::drain(WTF::MonotonicTime)::{lambda(JSC::MarkStackArray&)#1}>(JSC::SlotVisitor::drain(WTF::MonotonicTime)::{lambda(JSC::MarkStackArray&)#1} const&) (SlotVisitorInlines.h:184)
==125==    by 0x31581DE: JSC::SlotVisitor::drain(WTF::MonotonicTime) (SlotVisitor.cpp:494)
==125==    by 0x3159373: JSC::SlotVisitor::donateAndDrain(WTF::MonotonicTime) (SlotVisitor.cpp:777)
==125==    by 0x3158E73: JSC::SlotVisitor::drainInParallel(WTF::MonotonicTime) (SlotVisitor.cpp:703)
==125==  Uninitialised value was created by a stack allocation
==125==    at 0x386C00D: JSC::JSGlobalObject::init(JSC::VM&) (JSGlobalObject.cpp:786)

I would have hoped that it would point us to the exact line where the uninitialized value is originating from. :( But knowing that it's coming from JSGlobalObject::init is still useful. That's unfortunately a pretty big function, but now we know the bug is probably *somewhere* there.

-- 
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/ecf55fe3/attachment.htm>