[gold][patch] Cleanup more mmap leakage

Cary Coutant ccoutant@google.com
Wed Apr 7 22:23:00 GMT 2010


Ping...

On Fri, Mar 26, 2010 at 4:13 PM, Cary Coutant <ccoutant@google.com> wrote:
> This patch fixes some more mmap leakage that I've found in processing
> thin archives, shared libraries, and during garbage collection. As far
> as I can tell now, --no-keep-files-mapped now releases all the memory
> it should between passes. These fixes reduce gold's maximum memory
> usage slightly, but didn't make any significant performance difference
> on the tests I ran.
>
> In most cases, gold is careful to explicitly delete File_view objects
> as soon as they are no longer needed, but there were unusual code
> paths (e.g., when a shared library is added a second time) that were
> missing those explicit delete statements. I chose to add destructors
> to make sure that all File_view members are deleted when
> Read_symbols_data and Read_relocs_data objects are destroyed, and to
> make sure that the Read_symbols_data and Read_relocs_data objects are
> destroyed before releasing the associated file (so that
> File_read::clear_views would unmap the regions). I didn't bother to
> remove the places where the File_view objects were explicitly deleted,
> since in those places it's still better to delete them as early as
> possible.
>
> No regressions on x86_64. OK to checkin?
>
> -cary
>
>        * archive.cc (include_member): Destroy Read_symbols_data object before
>        releasing file.
>        * object.cc (Read_symbols_data::~Read_symbols_data) New destructor.
>        * object.h (Read_symbols_data::Read_symbols_data) New constructor.
>        (Read_symbols_data::~Read_symbols_data) New destructor.
>        (Section_relocs::Section_relocs) New constructor.
>        (Section_relocs::~Section_relocs) New destructor.
>        (Read_relocs_data::Read_relocs_data) New constructor.
>        (Read_relocs_data::~Read_relocs_data) New destructor.
>        * testsuite/binary_unittest.cc (Sized_binary_test): Set sd member
>        pointers to NULL after deleting.
>



More information about the Binutils mailing list