<div dir="ltr">Looking at this some more, there appears to be some cases where LLVM is causing memory leaks due to ManagedStatic (and perhaps undefined behavior).<div><br></div><div><br></div><div style>Example:</div><div style>
<br></div><div style>The expected client behavior is to call llvm_shutdown() before returning from main(). This causes destroy() to be called on all ManagedStatic instances that have been accessed so far, deleting the child data and NULLing out the StaticList global. This includes PassRegistry.</div>
<div style><br></div><div style>After main terminates, the global destructors run, including the command-line option destructors. The "-print-before" and "-print-after" options use a PassNameParser instance. This parser is a sub-class of PassRegistrationListener, and the destructor for this class calls PassRegistry::getPassRegistry(). This call accesses a ManagedStatic<PassRegistry> instance. But, all ManagedStatic instances have already been cleaned up! This brings up two issues/questions:</div>
<div style><br></div><div style>1. The ManagedStatic instance was cleaned-up, so the accessors re-create the object. Since all ManagedStatic instances were already cleaned-up, this new instance is leaked.</div><div style>
<br></div><div style>2. Is this not undefined behavior? There is no guarantee which objects are destructed when, so is it even valid to assume that the ManagedStatic instance is still usable? Couldn't the compile decide to write all 1s to the memory range used by the ManagedStatic instance? Or is there some guarantee that ManagedStatic is a POD type and won't be touched until after all global destructors run?</div>
<div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 13, 2013 at 7:54 AM, Justin Holewinski <span dir="ltr"><<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Right, I'm suggesting we keep llvm_shutdown() for users who want this control, but also destroy still-live ManagedStatic instances if llvm_shutdown() is not called. This helps in the case where there is not a clear time when llvm_shutdown() can be called, especially given that LLVM cannot be resurrected in the same process due to current limitations in the pass registry, and perhaps elsewhere.</div>
<div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Wed, Feb 13, 2013 at 7:47 AM, Nicholas Chapman <span dir="ltr"><<a href="mailto:admin@indigorenderer.com" target="_blank">admin@indigorenderer.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Hi Justin,<br>
I don't know anything about the details of llvm_shutdown and the
ManagedStatic implementation.<br>
But it's nice to be able to explicitly free memory allocated by
LLVM, otherwise such memory (allocated by global objects) can show
up as memory leaks.<br>
<br>
Thanks,<br>
Nick C.<div><div><br>
<pre cols="72"></pre>
On 12/02/2013 6:31 p.m., Justin Holewinski wrote:<br>
</div></div></div>
<blockquote type="cite"><div><div>
<div dir="ltr">Ping. Anyone with knowledge of detailed knowledge
of the ManagedStatic implementation?
<div><br>
</div>
<div>The use-case we are looking at is getting rid of
llvm_shutdown() by cleaning up the ManagedStatic data when the
global destructors run.</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sat, Feb 9, 2013 at 5:25 PM, Justin
Holewinski <span dir="ltr"><<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I'm curious about the design rationale for
how ManagedStatic instances are cleaned up, and I'm hoping
someone can shed some light on it.
<div>
<br>
</div>
<div>Currently, ManagedStatic objects are cleaned up when
llvm_shutdown() traverses the global list of initialized
objects and calls destroy() on each. This leads to two
questions:</div>
<div><br>
</div>
<div>1. An assertion enforces that the objects are deleted
in reverse order of allocation. Is there any hard
requirement for this, or is it only because of the way
the linked list is created?</div>
<div><br>
</div>
<div>2. Would anything change (functionally) if we simply
called destroy() in the ManagedStatic destructor?
Wouldn't this be safer than relying on a client to call
llvm_shutdown()? It seems like the whole purpose of
llvm_shutdown() is to allow clients to free the data
allocated by ManagedStatic instances. Could we not just
give them an option, but by default clean up during
global destruction?<span><font color="#888888"><br clear="all">
<div><br>
</div>
-- <br>
<br>
<div>Thanks,</div>
<div><br>
</div>
<div>Justin Holewinski</div>
</font></span></div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<br>
<div>Thanks,</div>
<div><br>
</div>
<div>Justin Holewinski</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br>
</div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</div>