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

[bugzilla-daemon at webkit.org]

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

--- Comment #19 from Michael Catanzaro <mcatanzaro at gnome.org> ---
(In reply to Mark Lam from comment #18)
> As Justin explained in
> https://webkit.slack.com/archives/CU5LWFM28/
> p1668090516378259?thread_ts=1668089239.370399&cid=CU5LWFM28, Valgrind makes
> assumptions about how the code works.  Valgrind is not knowledgeable about
> how JSC works, and JSC does a lot of advance and tricky algorithms that
> Valgrind has no way to know about.  As a result, you'll just be looking at a
> lot (possibly, all) false positives.  If you want to continue to use it,
> you're on your own on deciphering whether the reported error is real or one
> of the many false positives that Valgrind will report.
>
> Right now, your data suggests that there may be a missing write barrier. 

valgrind's memcheck tool is not prone to false positives, unless you are running leak check. (The leak check likes to complain about one-time leaks that may be intentional. It may also complain if you're doing something seriously weird.) Except for leak check results, I'd be surprised if memcheck discovers anything that's not either a real bug or at least non-ideal behavior that's worth fixing. It's really not normal for valgrind to report memory errors. The most benign result I ever saw turned out to be WebKit IPC writing uninitialized padding bytes to the IPC socket, which was harmless because the WebKit process on the other end of the pipe would just ignore them, but we still fixed that to ensure that running cleanly with valgrind is possible.

In this case, looking at comment #8, I see that JSC is reading the value of uninitialized memory. That does not look benign. Also, the uninitalized read in the JSC::WriteBarrier class, which is pretty concerning considering your comment above regarding the possibility that there may be a missing write barrier! :) Based on the line numbers, it's clear that WriteBarrierBase::m_cell is being read by a call to WriteBarrierBase::cell before it is initialized, so the value of the StorageType returned by that call is undefined behavior. I don't know for certain whether it's relevant to this crash, but it is being called by JSC::SlotVisitor, so... seems like a pretty decent chance this is related. At the very least, it's bad.

If WriteBarrierBase::m_cell were initialized to a default value, that would avoid the complaints from valgrind.

-- 
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/20221115/2dadf20e/attachment-0001.htm>