[llvm-dev] [RFC] Free memory allocated for ManagedStaticMutex

Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 22 13:56:36 PDT 2018


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.

On Mon, Oct 15, 2018 at 3:54 AM Sotkin, Alexey via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
>
>
>
> In llvm_shutdown function we destroy all objects in the StaticList. This
> procedure as well as RegisterManagedStatic are guarded by
> ManagedStaticMutex which is a static pointer visible only in
> ManagedStatic.cpp. Memory for the mutex is allocated at initializeMutex
> function and we never free this memory. From my experience this can cause a
> memory leak problem if we create a dll linked with LLVM libraries and the
> dll gets loaded(LoadLibrary Windows API) and unload(FreeLibrary Windows
> API) at runtime many times.
>
> My proposal is to provide deleteManagedStaticMutex LLVM API, so we can
> deallocate the mutex from DllMain on Windows. Please take a look at
> https://reviews.llvm.org/D52425
>
> I also think it’s worth adding deleteManagedStaticMutex to
> llvm_shutdown_obj’s destructor. I have attached valgrind logs with and
> without deleting ManagedStaticMutex.
>
>
>
> *Best regards.*
>
> *Alexey Sotkin.*
>
>
>
>
> --------------------------------------------------------------------
> Joint Stock Company Intel A/O
> Registered legal address: Krylatsky Hills Business Park,
> 17 Krylatskaya Str., Bldg 4, Moscow 121614,
> Russian Federation
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181022/2751ef49/attachment.html>


More information about the llvm-dev mailing list