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)
Tracking
()
RESOLVED
INVALID
People
(Reporter: gkw, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: valgrind)
Attachments
(1 file, 1 obsolete file)
|
992 bytes,
text/plain
|
Details |
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.
|
Reporter | |
Updated•12 years ago
|
Blocks: valgrind-tbpl-bugs
|
|
Reporter | |
Updated•12 years ago
|
No longer blocks: valgrind-on-tbpl
|
||
Updated•12 years ago
|
Assignee: nobody → wtc
Component: Build Config → NSPR
Product: Core → NSPR
Version: Trunk → other
|
||
Comment 1•12 years ago
|
||
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.
|
|
||
Updated•12 years ago
|
Assignee: wtc → nobody
Component: NSPR → General
Product: NSPR → Core
Version: other → Trunk
|
|
||
Updated•12 years ago
|
Component: General → XPCOM
|
||
Comment 2•12 years ago
|
||
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
|
|
||
Updated•12 years ago
|
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
|
|
Reporter | |
Comment 3•12 years ago
|
||
Attachment #663952 -
Attachment is obsolete: true
You need to log in
before you can comment on or make changes to this bug.
Description
•