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

[Reid Kleckner via llvm-dev]

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.

On Mon, Oct 29, 2018 at 9:02 AM Justin Holewinski <
justin.holewinski at gmail.com> wrote:

> How does keeping the DLL in-memory help with not leaking the mutex? Or is
> the recommendation to just ignore the leak?
>
> On Fri, Oct 26, 2018 at 9:32 AM Sotkin, Alexey via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi Reid,
>>
>>
>>
>> Thanks for the feedback. Could you elaborate on pinning and dropping
>> topic. I don’t quite understand what do you mean.
>>
>>
>>
>> Thanks,
>>
>> Alexey Sotkin
>>
>> *From:* Reid Kleckner [mailto:rnk at google.com]
>> *Sent:* Monday, October 22, 2018 11:57 PM
>> *To:* Sotkin, Alexey <alexey.sotkin at intel.com>
>> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>; Maksimova, Viktoria <
>> viktoria.maksimova at intel.com>
>> *Subject:* Re: [llvm-dev] [RFC] Free memory allocated for
>> ManagedStaticMutex
>>
>>
>>
>> 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
>>
>>
>> --------------------------------------------------------------------
>> 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
>>
>
>
> --
>
> Thanks,
>
> Justin Holewinski
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181029/43c65325/attachment.html>