793535 - Valgrind on tbpl detects leak at calloc (32 bytes in 1 blocks are definitely lost) with _dlerror_run on the stack

Status: RESOLVED INVALID

(NSPR :: NSPR, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: Valgrind stack

Valgrind detects a leak of 32 bytes at calloc with _dlerror_run on the stack, see attached snippet which comes from:

https://tbpl.mozilla.org/php/getParsedLog.php?id=15457865&tree=Firefox&full=1

No idea which component is right, guessing at Core:Security for now, as PR_SetCurrentThreadName (in /builds/slave/m-cen-lnx64-valgrind/objdir/dist/firefox/libnspr4.so) is on the stack.

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

NSPR may be a better guess.

Comment 2

[Wan-Teh Chang]

gkw: thank you for the bug report.

This is a leak in the dlsym() function. dlsym() returns the address
of a symbol (usually a function), which does not need to be freed.
So we'll have to suppress this leak.

Please use this suppression:

{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   fun:calloc
   fun:_dlerror_run
   fun:dlsym
}

Do you see this leak in other call stacks?

You can reference this glibc bug report that I filed:
http://sourceware.org/bugzilla/show_bug.cgi?id=14015

Note that I didn't have time to follow up on that glibc
bug report.

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Wan-Teh, yes, we're adding that suppression at [1]. Thanks for the help with the diagnosis!

[1] http://mxr.mozilla.org/mozilla-central/source/build/valgrind/

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

> This is a leak in the dlsym() function. dlsym() returns the address
> of a symbol (usually a function), which does not need to be freed.
> So we'll have to suppress this leak.

-> INVALID based on this analysis.

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: m-c changeset 555f91476597 Valgrind stack with line numbers

Comment 6

[Nicholas Nethercote [inactive]]

> This is a leak in the dlsym() function. dlsym() returns the address
> of a symbol (usually a function), which does not need to be freed.
> So we'll have to suppress this leak.

Just to clarify:  this appears to be a leak within dlsym(), which is a 3rd party library and hence beyond our control.  So yes, suppressing is appropriate.