Fix tst-leaks1 (bug 14681)

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>

0 files changed, 0 insertions, 0 deletions