<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 15, 2016 at 6:38 AM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Lisandro Dalcin <<a href="mailto:dalcinl@gmail.com">dalcinl@gmail.com</a>> writes:<br>
<br>
> On 13 March 2016 at 04:21, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
>> You can fix the SEGV by moving the library unloading to after the malloc<br>
>> dump. However,<br>
>> it then records that the memory from loading the library is still unfreed.<br>
><br>
> Or let's do it the Python way and never ever dlclose() dynamic libraries :-)<br>
<br>
</span>If I understand correctly, this would be no different from calling<br>
dlclose after dealing with the malloc_dump.  And I think it's the right<br>
solution because otherwise we have to copy __func__ instead of just<br>
referencing it.  What is the "memory from loading the library"?<br>
</blockquote></div><br>The memory is the struct telling us what the libraries are to dclose. So either we</div><div class="gmail_extra">would copy that to memory we do not log, or we ignore that memory in the logging,</div><div class="gmail_extra">which is what I did.</div><div class="gmail_extra"><br></div><div class="gmail_extra">   Matt<br clear="all"><div><br></div>-- <br><div class="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>