Closed Bug 793535 Opened 12 years ago Closed 12 years ago

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

Categories

(NSPR :: NSPR, defect)

4.10
All
Linux
defect
Not set
major

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: gkw, Assigned: wtc)

References

(Blocks 1 open bug)

Details

(Keywords: valgrind)

Attachments

(1 file, 1 obsolete file)

Attached file Valgrind stack (obsolete) —
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.
Hardware: All → x86_64
Hardware: x86_64 → All
NSPR may be a better guess.
Assignee: nobody → wtc
Component: Security → NSPR
Product: Core → NSPR
Version: Trunk → 4.10
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.
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/
> 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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
> 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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: