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

[bugzilla-daemon at webkit.org]

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

--- Comment #34 from Yusuke Suzuki <ysuzuki at apple.com> ---
(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.

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