<div dir="ltr">I'm afraid, increasing the size of the chunks array for all platforms might not go that well with iOS and Android (look for ASAN_LOW_MEMORY for the reference). I'll think of the best way to handle it. Thank you, Frederik!</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 9, 2018 at 10:29 AM, Frederik Deweerdt <span dir="ltr"><<a href="mailto:frederik.deweerdt@gmail.com" target="_blank">frederik.deweerdt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<span class=""><br>
On Wed, Jan 24, 2018 at 4:22 PM, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>
><br>
><br>
> On Wed, Jan 24, 2018 at 12:10 PM, Frederik Deweerdt<br>
> <<a href="mailto:frederik.deweerdt@gmail.com">frederik.deweerdt@gmail.com</a>> wrote:<br>
</span>[...]<br>
<span class="">>><br>
>> > If yes, yea, I guess we need to bump kMaxNumChunks<br>
>> ><br>
>> ><br>
>> I'll increase the limit to 2^19 for our build, and I'll report the results<br>
>> here.<br>
><br>
><br>
</span>I ended up increasing the limit to 2^20, because the max allocation<br>
for large objects is around 100G on those hosts. With that done, i hit<br>
an issue where adding stacks to the StackDepot became a visible<br>
bottleneck after a few hours. To solve that, i've set<br>
`malloc_context_size=0`, because we're not tracking leaks, and in our<br>
experience getting the call site of the ASAN report carries enough<br>
information to diagnose the issue. With these two changes, the build<br>
is behaving as expected.<br>
If you think it's worth doing, i'm happy to post a patch for the<br>
constant increase.<br>
<br>
Thanks,<br>
Frederik<br>
</blockquote></div><br></div>