This is an archive of the discontinued LLVM Phabricator instance.

Fix memory leak in lib/Support/DynamicLibrary.cpp wrap OpenedHandles in llvm::ManagedStatic<>
Needs RevisionPublic

Authored by pkarneliuk on Apr 6 2015, 3:50 AM.

Details

Summary

This patch fixes a memory leak in Support library. Currently, the OpenedHandles is allocated dynamically and never deallocated. This patch wraps a raw pointer in llvm::ManagedStatic<> template. So, the registry of open handles will be managed by LLVM routines for static variables (llvm::llvm_shutdown()).

This patch is close to that https://github.com/llvm-mirror/llvm/commit/b4b9b3b24c03f414c54f55e1b34b4d9124c55883 patch.
I have removed fixme-message in the header.

Diff Detail

Event Timeline

pkarneliuk updated this revision to Diff 23265.Apr 6 2015, 3:50 AM
pkarneliuk retitled this revision from to Fix memory leak in lib/Support/DynamicLibrary.cpp wrap OpenedHandles in llvm::ManagedStatic<>.
pkarneliuk updated this object.
pkarneliuk edited the test plan for this revision. (Show Details)
pkarneliuk added reviewers: chandlerc, Bigcheese.
pkarneliuk added a subscriber: Unknown Object (MLST).
pkarneliuk accepted this revision.Apr 6 2015, 3:54 AM
pkarneliuk added a reviewer: pkarneliuk.
This revision is now accepted and ready to land.Apr 6 2015, 3:54 AM
pkarneliuk requested a review of this revision.Apr 6 2015, 8:40 AM
pkarneliuk edited edge metadata.
chandlerc requested changes to this revision.Apr 14 2015, 7:56 AM
chandlerc edited edge metadata.

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)

This revision now requires changes to proceed.Apr 14 2015, 7:56 AM

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@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
  1. 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/