[Bug dynamic-link/14015] _dlerror_run leaks memory when called by dlsym
ppluzhnikov at google dot com
sourceware-bugzilla@sourceware.org
Tue Apr 24 20:42:00 GMT 2012
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.
More information about the Glibc-bugs
mailing list