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/14015] _dlerror_run leaks memory when called by dlsym


http://sourceware.org/bugzilla/show_bug.cgi?id=14015

Paul Pluzhnikov <ppluzhnikov at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |ppluzhnikov at google dot
                   |                            |com
         AssignedTo|unassigned at sourceware    |ppluzhnikov at google dot
                   |dot org                     |com

--- Comment #1 from Paul Pluzhnikov <ppluzhnikov at google dot com> 2012-04-24 20:41:45 UTC ---
(In reply to comment #0)

> On Ubuntu 10.04.2 LTS, I get this output from valgrind:
...
> ==12203== 32 bytes in 1 blocks are still reachable in loss record 1 of 1
> ==12203==    at 0x4C297FA: calloc (vg_replace_malloc.c:565)
> ==12203==    by 0x4E3431F: _dlerror_run (dlerror.c:142)
> ==12203==    by 0x4E34079: dlsym (dlsym.c:71)
> ==12203==    by 0x40059D: main (in /home/wtc/tmp/a.out)

There is nothing wrong with that.

The code reads:

      result = __libc_getspecific (key);
      if (result == NULL)
    {
      result = (struct dl_action_result *) calloc (1, sizeof (*result));
      if (result == NULL)
        /* We are out of memory.  Since this is no really critical
           situation we carry on by using the global variable.
           This might lead to conflicts between the threads but
           they soon all will have memory problems.  */
        result = &last_result;
      else
        /* Set the tsd.  */
        __libc_setspecific (key, result);
    }

The only way I can think of for this to become a definite leak is if
someone corrupts thread-specific storage, or terminates the thread in some
"unnatural" way.

This is perhaps best debugged internally to Google.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- 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]