[PATCH] Fix memory leak in lib/Support/DynamicLibrary.cpp wrap OpenedHandles in llvm::ManagedStatic<>

Pavel Karneliuk pavel.karneliuk at gmail.com
Tue Apr 14 08:44:32 PDT 2015


Hi Chandler,

Ok, this object is reachable and is never deallocated. Is it design
decision or a piece of legacy code?
We can deallocate it via llvm::ManagedStatic<> at the shutdown. Similar to
next object:
static llvm::ManagedStatic<llvm::sys::SmartMutex<true> > SymbolsMutex;
This SymbolsMutex are used in static functions of DynamicLibrary module. We
already rely on this ownership routines for static variables.

This patch fixes legacy code and deallocates object stored in static
variable.
It looks like the patch requires some changes.
How I should rewrite it?

There is already accepted patch with similar changes:
https://github.com/llvm-mirror/llvm/commit/b4b9b3b24c03f414c54f55e1b34b4d9124c55883
This patch is a finish of his work.

Thanks,
Pavel K





2015-04-14 17:56 GMT+03:00 Chandler Carruth <chandlerc at gmail.com>:

> Please see the comments David sent to the mailing list about this patch.
> I've quoted them below:
>
> > This is one of those "what is a leak" existential questions.
>
> >
>
> > There are two common attitudes/interpretations:
>
> >
>
> > 1. Memory that is unreachable
>
> > 2. Memory that is never deallocated
>
> >
>
> > Most tools have been taught to only report (1) and ignore (2).
>
> >
>
> > This idiom (allocating and never deallocating globals) is sometimes used
> to avoid global destructors which can be dangerously racy (if a
> multithreaded program is shutting down (possibly due to exceptions, etc)
> and hasn't stopped all its worker threads, it could be problematic to try
> to destroy globals that may still be in use by other threads - leading to
> failure-on-failure modes that can make debugging the original failure more
> difficult)
>
>
>
> http://reviews.llvm.org/D8838
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150414/51a54ae6/attachment.html>


More information about the llvm-commits mailing list