Re: [PATCH] Fix tst-leaks1 (bug 14681)

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Tue, Dec 12, 2017 at 8:40 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> The test tst-leaks1 exercises calling dlopen with a $ORIGIN DST.
>
> This results in a theoretical leak e.g.
>
> Memory not freed:
> -----------------
>            Address     Size     Caller
> 0x0000000001d766c0     0x21  at 0x7fb1bd8bf4ab
>
> Or as seen via valgrind:
>
> ==27582== 33 bytes in 1 blocks are still reachable in loss record 1 of 1
> ==27582==    at 0x4C2CB6B: malloc (vg_replace_malloc.c:299)
> ==27582==    by 0x40124AA: _dl_get_origin (dl-origin.c:50)
> ==27582==    by 0x4007DB9: expand_dynamic_string_token (dl-load.c:382)
> ==27582==    by 0x400899C: _dl_map_object (dl-load.c:2160)
> ==27582==    by 0x4013020: dl_open_worker (dl-open.c:224)
> ==27582==    by 0x5166F9B: _dl_catch_exception (dl-error-skeleton.c:198)
> ==27582==    by 0x4012BD9: _dl_open (dl-open.c:594)
> ==27582==    by 0x4E39EF5: dlopen_doit (dlopen.c:66)
> ==27582==    by 0x5166F9B: _dl_catch_exception (dl-error-skeleton.c:198)
> ==27582==    by 0x516700E: _dl_catch_error (dl-error-skeleton.c:217)
> ==27582==    by 0x4E3A514: _dlerror_run (dlerror.c:162)
> ==27582==    by 0x4E39F70: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
>
> There is no real leak.
>
> The calling link map (the executable's link map) has it's l_origin
> expanded for future use as part of _dl_get_origin, and that results
> in the main executable link map having a N-byte allocation for
> l->l_origin that is never freed since the executable's link map is
> just a part of the process.
>
> To take this into account we do one dlopen with $ORIGIN before
> calling mtrace to force the initialization of the executable link
> map.
>
> Signed-off-by: Carlos O'Donell <carlos@redhat.com>
>
> OK to checkin?
>

LGTM.

Thanks.


-- 
H.J.