<div dir="ltr">The leak is that when the DLL is reloaded, it is allocated again. If you prevent the DLL from ever being unloaded, there's no accumulation, just some memory that lives for the entire process lifetime.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 29, 2018 at 9:02 AM Justin Holewinski <<a href="mailto:justin.holewinski@gmail.com">justin.holewinski@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">How does keeping the DLL in-memory help with not leaking the mutex? Or is the recommendation to just ignore the leak?<br><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 9:32 AM Sotkin, Alexey via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">







<div link="blue" vlink="purple" lang="RU">
<div class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d" lang="EN-US">Hi Reid,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d" lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d" lang="EN-US">Thanks for the feedback. Could you elaborate on pinning
 and dropping topic. I don’t quite understand what do you mean.<u></u><u></u></span></p>
<p class="MsoNormal"><a name="m_3153717663513278531_m_-4129280491507621258_m_-516215869061091643__MailEndCompose"><span lang="EN-US"><u></u> <u></u></span></a></p>
<p class="MsoNormal"><span><span lang="EN-US">Thanks,<u></u><u></u></span></span></p>
<p class="MsoNormal"><span><span lang="EN-US">Alexey Sotkin<u></u><u></u></span></span></p>
<span></span>
<p class="MsoNormal"><a name="m_3153717663513278531_m_-4129280491507621258_m_-516215869061091643______replyseparator"></a><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif" lang="EN-US">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif" lang="EN-US">
 Reid <span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE">Kleckner</span> [mailto:<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>] <br>
<b>Sent:</b> Monday, October 22, 2018 11:57 PM<br>
<b>To:</b> Sotkin, Alexey <<a href="mailto:alexey.sotkin@intel.com" target="_blank">alexey.sotkin@intel.com</a>><br>
<b>Cc:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; Maksimova, Viktoria <<a href="mailto:viktoria.maksimova@intel.com" target="_blank">viktoria.maksimova@intel.com</a>><br>
<b>Subject:</b> Re: [llvm-dev] [RFC] Free memory allocated for <span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE">
ManagedStaticMutex</span><u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Let's not do this. It's really best for global mutexes to live for the entire process lifetime. Initializing them and deinitializing them just asks for races. Perhaps you can avoid this problem by pinning your LLVM DLL in memory by LoadLibrary'ing
 it and dropping the reference.<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Oct 15, 2018 at 3:54 AM Sotkin, Alexey via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">Hi,</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US">In
<span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE"><span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643m5837773912688951461spelle">llvm_shutdown</span></span> function we destroy all objects in the
<span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE"><span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643m5837773912688951461spelle">StaticList</span></span>. This procedure as well as
<span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE"><span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643m5837773912688951461spelle">RegisterManagedStatic</span></span> are guarded by
<span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE"><span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643m5837773912688951461spelle">ManagedStaticMutex</span></span> which is a static pointer visible only in ManagedStatic.cpp. Memory for the
<span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE"><span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643m5837773912688951461spelle">mutex</span></span> is allocated at
<span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE"><span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643m5837773912688951461spelle">initializeMutex</span></span> function and we never free this memory. From my experience this can cause a memory leak problem if we create a
<span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE"><span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643m5837773912688951461spelle">dll</span></span> linked with LLVM libraries and the
<span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE"><span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643m5837773912688951461spelle">dll</span></span> gets loaded(<span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE"><span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643m5837773912688951461spelle">LoadLibrary</span></span> Windows API) and unload(<span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE"><span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643m5837773912688951461spelle">FreeLibrary</span></span>
 Windows API) at runtime many times.</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US">My proposal is to provide
<span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE"><span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643m5837773912688951461spelle">deleteManagedStaticMutex</span></span> LLVM API, so we can deallocate the
<span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE"><span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643m5837773912688951461spelle">mutex</span></span> from
<span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE"><span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643m5837773912688951461spelle">DllMain</span></span> on Windows. Please take a look at
<a href="https://reviews.llvm.org/D52425" target="_blank">https://reviews.llvm.org/D52425</a>
</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US">I also think it’s worth adding
<span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE"><span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643m5837773912688951461spelle">deleteManagedStaticMutex</span></span> to
<span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE"><span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643m5837773912688951461spelle">llvm_shutdown_obj’s</span></span> destructor. I have attached
<span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE"><span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643m5837773912688951461spelle">valgrind</span></span> logs with and without deleting
<span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643SpellE"><span class="m_3153717663513278531m_-4129280491507621258m_-516215869061091643m5837773912688951461spelle">ManagedStaticMutex</span></span>.</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p>
<p class="MsoNormal"><i><span lang="EN-US">Best regards.</span></i><u></u><u></u></p>
<p class="MsoNormal"><i><span lang="EN-US">Alexey Sotkin.</span></i><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p>
</div>
<p><br>
--------------------------------------------------------------------<br>
Joint Stock Company Intel A/O<br>
Registered legal address: Krylatsky Hills Business Park, <br>
17 Krylatskaya Str., Bldg 4, Moscow 121614, <br>
Russian Federation<u></u><u></u></p>
<p>This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.<u></u><u></u></p>
</div>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</blockquote>
</div>
</div>
<p><br>--------------------------------------------------------------------<br>Joint Stock Company Intel A/O<br>Registered legal address: Krylatsky Hills Business Park, <br>17 Krylatskaya Str., Bldg 4, Moscow 121614, <br>Russian Federation</p><p>This e-mail and any attachments may contain confidential material for<br>the sole use of the intended recipient(s). Any review or distribution<br>by others is strictly prohibited. If you are not the intended<br>recipient, please contact the sender and delete all copies.</p>
</div>

_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="m_3153717663513278531m_-4129280491507621258gmail_signature" data-smartmail="gmail_signature"><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div></div></div></div>
</blockquote></div>