This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/15859] New: Memory leak detected in _dl_map_object_deps()
- From: "Vinitha.Vijayann at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 20 Aug 2013 10:11:53 +0000
- Subject: [Bug dynamic-link/15859] New: Memory leak detected in _dl_map_object_deps()
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=15859
Bug ID: 15859
Summary: Memory leak detected in _dl_map_object_deps()
Product: glibc
Version: 2.11
Status: NEW
Severity: normal
Priority: P2
Component: dynamic-link
Assignee: unassigned at sourceware dot org
Reporter: Vinitha.Vijayann at gmail dot com
Created attachment 7152
--> http://sourceware.org/bugzilla/attachment.cgi?id=7152&action=edit
Testcode to reproduce the issue
Hi,
A memory leak is observed inside _dl_map_object_deps(). The following malloc()
causes leak
...
l_reldeps = malloc (sizeof (*l_reldeps)
+ map->l_reldepsmax
* sizeof (struct link_map *));
...
The issue can be reproduced using a minimal test scenario which is shown below
...
* libX.so
\--------> libA.so
\--------> libB.so
\--------> libC.so
* libA.so
\-------> libB.so
\........................> libC.so ( relocation dependency)
* libB.so
\-------> libC.so
* main application
{
...
dlopen(libX.so);
...
dlopen(libA.so)
}
...
Testcode to reproduce this issue is attached.
The valgrind output is shown below (Tested for glibc-2.11.2)
...
# export LD_LIBRARY_PATH=.
# valgrind --tool=memcheck --leak-check=full ./main
==384== Memcheck, a memory error detector
==384== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==384== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==384== Command: ./main
==384==
++++++++++ dlopen [libX.so] : [1]
++++++++++ dlopen [libA.so] : [2]
==384==
==384== HEAP SUMMARY:
==384== in use at exit: 44 bytes in 1 blocks
==384== total heap usage: 26 allocs, 25 frees, 3,660 bytes allocated
==384==
==384== 44 bytes in 1 blocks are definitely lost in loss record 1 of 1
==384== at 0x482F9C8: malloc (vg_replace_malloc.c:270)
==384== by 0x4009DF7: _dl_map_object_deps (dl-deps.c:593)
==384== by 0x400E3DD: dl_open_worker (dl-open.c:262)
==384== by 0x400AEE9: _dl_catch_error (dl-error.c:178)
==384== by 0x400E001: _dl_open (dl-open.c:554)
==384== by 0x483FB4F: dlopen_doit (dlopen.c:67)
==384== by 0x400AEE9: _dl_catch_error (dl-error.c:178)
==384== by 0x483FFC1: _dlerror_run (dlerror.c:164)
==384== by 0x483FBCF: dlopen@@GLIBC_2.4 (dlopen.c:88)
==384== by 0x8547: main (in /root/test/main)
==384==
==384== LEAK SUMMARY:
==384== definitely lost: 44 bytes in 1 blocks
==384== indirectly lost: 0 bytes in 0 blocks
==384== possibly lost: 0 bytes in 0 blocks
==384== still reachable: 0 bytes in 0 blocks
==384== suppressed: 0 bytes in 0 blocks
==384==
==384== For counts of detected and suppressed errors, rerun with: -v
==384== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 39 from 12)
...
The issue is present in latest version of glibc also. It happens because of
duplicate declaration of pointer l_reldeps as shown below
...
struct link_map_reldeps *l_reldeps = NULL; ===> HERE
if (map->l_reldeps != NULL)
{
for (i = 1; i < nlist; ++i)
map->l_searchlist.r_list[i]->l_reserved = 1;
struct link_map **list = &map->l_reldeps->list[0];
for (i = 0; i < map->l_reldeps->act; ++i)
if (list[i]->l_reserved)
{
/* Need to allocate new array of relocation dependencies. */
struct link_map_reldeps *l_reldeps; ===> HERE
l_reldeps = malloc (sizeof (*l_reldeps)
+ map->l_reldepsmax
* sizeof (struct link_map *));
...
The fix is to remove the duplicate declaration inside the if loop.
Fix patch is attached to the ticket.
Regards,
Vinitha Vijayan
Sony India Software Centre Pvt Ltd
--
You are receiving this mail because:
You are on the CC list for the bug.