Closed Bug 793611 Opened 12 years ago Closed 12 years ago

Valgrind on tbpl detects leak - 4 bytes are definitely lost (direct) with __tls_get_addr (in ld.so) on the stack

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: gkw, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: valgrind)

Attachments

(1 file, 1 obsolete file)

m-c changeset 555f91476597 Valgrind stack with line numbers
992 bytes, text/plain
Details
Attached file Valgrind stack (obsolete) — 
Valgrind detects a leak of 4 bytes (direct) with ld entries on the stack, see attached snippet which comes from:

https://tbpl.mozilla.org/php/getParsedLog.php?id=15471615&tree=Firefox

Guessing Core: Build Config, please change component if necessary.
Assignee: nobody → wtc
Component: Build Config → NSPR
Product: Core → NSPR
Version: Trunk → other
I think this should be investigated by the owner of
nsThread::ProcessNextEvent. I am not familiar with
__tls_get_addr. This is probably a leak in the
"tls" (thread local storage) system.
Assignee: wtc → nobody
Component: NSPR → General
Product: NSPR → Core
Version: other → Trunk
Component: General → XPCOM
I don't think this is a bug at all, it's just how glibc/ld.so manages TLS allocations, but in any case it's not something this project will fix.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Summary: Valgrind on tbpl detects leak - 4 bytes are definitely lost (direct) with ld entries on the stack → Valgrind on tbpl detects leak - 4 bytes are definitely lost (direct) with __tls_get_addr (in ld.so) on the stack
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: