<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - regress/script-tests/double-pollution-putbyoffset.js.ftl-eager timed out because of a lock ordering deadlock involving InferredType and CodeBlock"
href="https://bugs.webkit.org/show_bug.cgi?id=154841#c1">Comment # 1</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - regress/script-tests/double-pollution-putbyoffset.js.ftl-eager timed out because of a lock ordering deadlock involving InferredType and CodeBlock"
href="https://bugs.webkit.org/show_bug.cgi?id=154841">bug 154841</a>
from <span class="vcard"><a class="email" href="mailto:fpizlo@apple.com" title="Filip Pizlo <fpizlo@apple.com>"> <span class="fn">Filip Pizlo</span></a>
</span></b>
<pre>Here's the deadlock:
Main thread:
1) Change an InferredType. This acquires InferredType::m_lock.
2) Fire watchpoint set. This triggers CodeBlock invalidation, which acquires CodeBlock::m_lock.
DFG thread:
1) Iterate over the information in a CodeBlock. This acquires CodeBlock::m_lock.
2) Ask an InferredType for its descriptor(). This acquires InferredType::m_lock.
I think that the DFG thread's ordering should be legal, because the best logic for lock hierarchies is that locks that protect the largest set of stuff should be acquired first.
This means that the main thread shouldn't be holding the InferredType::m_lock when firing watchpoint sets. I think that we already do magic for this in other places.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>