<div dir="ltr">On Fri, Jul 3, 2015 at 3:10 AM, Mario Sanchez Prada <span dir="ltr"><<a href="mailto:mario@webkit.org" target="_blank">mario@webkit.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 03/07/15 10:47, Ryosuke Niwa wrote:<br>
> On Fri, Jul 3, 2015 at 2:32 AM, Mario Sanchez Prada <<a href="mailto:mario@webkit.org" target="_blank">mario@webkit.org</a><br>
</span>> [...]<br>
<span>> FWIW, I've tried reducing the scope of this flag to bmalloc but the crash<br>
> was still there. However, passing it instead for WebCore only did "fix" the<br>
> situation, so perhaps the problem is not strictly related to bmalloc, but to<br>
> something else in the graphics subsystem?<br>
><br>
> I could also be a bug on GCC, though.<br>
><br>
> Perhaps you can compare two diassembled bmalloc code with or without<br>
> -fno-tree-sra since bmallc is a fairly small project?<br>
<br>
</span>Not sure that would be useful, since enabling or disabling that -ftree-sra<br>
while building bmalloc does not make any difference wrt to this problem, but<br>
perhaps I'm overlooking something.<br>
<br>
The crash goes away when passing -fno-tree-sra for WebCore, unfortunately.<br></blockquote><div><br></div><div>That's interesting. It could be a real bug in WebCore like us relying on some undefined behavior that happens to work fine in clang.</div><div><br></div><div>We've had bugs like that in the past where what we thought would be a null pointer crash turned into a use-after-free because accessing null pointer results in undefined behavior and clang was taking the advantage of that in its optimizer.</div><div><br></div><div>- R. Niwa</div><div><br></div></div></div></div>