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

[bugzilla-daemon at webkit.org]

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

--- Comment #35 from Krzysztof Konopko <kris at youview.com> ---
(In reply to Yusuke Suzuki from comment #34)
> (In reply to Michael Catanzaro from comment #33)
> > (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....
> 
> It is conservative GC stack scanning, so valgrind isn't correctly
> understanding it.

OK, so if it all can be explained as reasonable and Valgdrind warnings are a red herring, then fair enough.  Nothing to see here.

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