This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug dynamic-link/15859] New: Memory leak detected in _dl_map_object_deps()


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]