[Webkit-unassigned] [Bug 208642] REGRESSION: (r257905) [ Mac wk2 Debug ] ASSERTION FAILED: !m_isolatedWorld->isNormal() || m_wrapper || !m_jsFunction

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Mar 6 01:20:20 PST 2020


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

--- Comment #22 from Yusuke Suzuki <ysuzuki at apple.com> ---
I think this is more fundamental problem which is not tied to HTMLVideoElement case.
For any node, this race condition happens if,

1. Node (A) is attached to the tree (TA).
2. (A)'s wrapper is marked and (TA) is registered as an opaque root.
3. The user code removes (A) from (TA).
4. Node (B), which is under (A), is invoking is-reachable-from-opaque-root query.
5. Node (B)'s root is (A) since (A) is detached from the tree (TA).
6. (4) cannot find the (A) from the set of opaque roots.

Let's consider about the fundamental fix. Every time we change the root, we need to emit "write-barrier" to this node.
Then, GC rescans it, re-register the updated root. So, the problem is how to emit "write-barrier" while we only have C++ node.

So the question is how to achieve this effect. One idea I have right now is, (1) when changing the root, (2) if GC is not running right now, noop, (2) otherwise, let's check the old root is included in the opaque root, (3) if it is included, we put the new root into the opaque root as something like remember-set mechanism. Then, conservatively we collect the necessary opaque roots. And once GC cycles pass, opaque root set is anyway cleared again. This works at least for main thread since we can access these data via commonVM().

-- 
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/20200306/28624cad/attachment.htm>


More information about the webkit-unassigned mailing list