<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 10, 2016 at 11:06 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10 November 2016 at 14:03, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> On Thu, Nov 10, 2016 at 6:47 AM, Rafael Espíndola<br>
> <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
>><br>
>> On 10 November 2016 at 00:28, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
>> > I think we could add a new member function to SpecificBumpPtrAllocator<br>
>> > to<br>
>> > discard all objects without calling their dtors. Now that almost all<br>
>> > objects<br>
>> > are allocated from the pool, so if we call that function before exiting,<br>
>> > exit should be as fast as _exit.<br>
>><br>
>> But is then the static destructors run the risk of accessing freed memory,<br>
>> no?<br>
><br>
><br>
> How does it happen?<br>
<br>
</span>It seems too easy to have a global that points to a pool allocated entry.<br></blockquote><div><br></div><div>They shouldn't use objects allocated from the pool from the dtor in the first place because even now the pool may be freed earlier than the other globals, no? </div></div></div></div>