<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - REGRESSION (r182899): icloud.com crashes"
href="https://bugs.webkit.org/show_bug.cgi?id=143960#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - REGRESSION (r182899): icloud.com crashes"
href="https://bugs.webkit.org/show_bug.cgi?id=143960">bug 143960</a>
from <span class="vcard"><a class="email" href="mailto:basile_clement@apple.com" title="Basile Clement <basile_clement@apple.com>"> <span class="fn">Basile Clement</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=143960#c2">comment #2</a>)
<span class="quote">> Comment on <span class=""><a href="attachment.cgi?id=251185&action=diff" name="attach_251185" title="Possible patch, regression test forthcoming">attachment 251185</a> <a href="attachment.cgi?id=251185&action=edit" title="Possible patch, regression test forthcoming">[details]</a></span>
> Possible patch, regression test forthcoming
>
> View in context:
> <a href="https://bugs.webkit.org/attachment.cgi?id=251185&action=review">https://bugs.webkit.org/attachment.cgi?id=251185&action=review</a>
>
> > Source/JavaScriptCore/dfg/DFGWatchpointCollectionPhase.cpp:113
> > + case AllocationProfileWatchpoint: {
> > + InlineWatchpointSet* watchpointSet = m_node->castOperand<JSFunction*>()->allocationProfileWatchpointSet();
> > + if (watchpointSet)
> > + addLazily(*watchpointSet);
> > break;
> > + }
>
> If watchpointSet is null, the compiler will fail to add a necessary
> watchpoint, which means that we'll end up with incorrect code if the
> watchpoint fires.
>
> Can we ASSERT that watchpointSet is not null instead of checking?
>
> What guarantees that it will not be null?</span >
If the watchpointSet is null, it means there is no rare data and thus there shouldn't be an AllocationProfileWatchpoint for this node.
A least that was the case before I made the allocation profile clearing too aggressive when the .prototype is overwritten.
This can only appear in the case of a singleton constructor whose prototype is overwritten after having been already constructed in the DFG, then constructed again, so no wonder the test cases did not catch this.
I am writing a proper fix now.</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>