TM: valgrind complains of a leak in js_RecordTree

RESOLVED WORKSFORME

Status

()

Core
JavaScript Engine
--
minor
RESOLVED WORKSFORME
10 years ago
9 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

({memory-leak, testcase, valgrind})

Trunk
x86
Mac OS X
memory-leak, testcase, valgrind
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
Using Mac, valgrind r9121, TM rev:54023cd2177c+:

cat c.js
for(i=0;i<9;++i){}

valgrind --leak-check=full ~/tracemonkey/js/src/debug/js -j ~/c.js

==91311== 220 (76 direct, 144 indirect) bytes in 1 blocks are definitely lost in loss record 41 of 69
==91311==    at 0x25FCE9: calloc (in /usr/local/lib/valgrind/x86-darwin/vgpreload_memcheck.so)
==91311==    by 0xE08EC: avmplus::GCObject::operator new(unsigned long, avmplus::GC*) (in /Users/jruderman/tracemonkey/js/src/debug/js)
==91311==    by 0x1399E5: js_RecordTree(JSContext*, JSTraceMonitor*, nanojit::Fragment*, nanojit::Fragment*, unsigned int, Queue<unsigned short>*) (in /Users/jruderman/tracemonkey/js/src/debug/js)
==91311==    by 0x14A5DF: js_MonitorLoopEdge(JSContext*, unsigned int&) (in /Users/jruderman/tracemonkey/js/src/debug/js)
==91311==    by 0x6FD19: js_Interpret (in /Users/jruderman/tracemonkey/js/src/debug/js)
==91311==    by 0x8FA6B: js_Execute (in /Users/jruderman/tracemonkey/js/src/debug/js)
==91311==    by 0x1CF25: JS_ExecuteScript (in /Users/jruderman/tracemonkey/js/src/debug/js)
==91311==    by 0x7890: Process(JSContext*, JSObject*, char*, int) (in /Users/jruderman/tracemonkey/js/src/debug/js)
==91311==    by 0x8FCB: ProcessArgs(JSContext*, JSObject*, char**, int) (in /Users/jruderman/tracemonkey/js/src/debug/js)
==91311==    by 0xA1D2:  (in /Users/jruderman/tracemonkey/js/src/debug/js)
==91311==    by 0x1B3A: (below main) (in /Users/jruderman/tracemonkey/js/src/debug/js)
==91311==    by 0x1A68: start (in /Users/jruderman/tracemonkey/js/src/debug/js)
This is loss record 41 of 69... is this (alleged) leak more notable than any of the others?
(Reporter)

Comment 2

10 years ago
==61551== LEAK SUMMARY:
==61551==    definitely lost: 76 bytes in 1 blocks.
==61551==    indirectly lost: 144 bytes in 3 blocks.
==61551==      possibly lost: 44 bytes in 1 blocks.
==61551==    still reachable: 192,584 bytes in 1,392 blocks.
==61551==         suppressed: 0 bytes in 0 blocks.
==61551== Reachable blocks (those to which a pointer was found) are not shown.
==61551== To see them, rerun with: --leak-check=full --show-reachable=yes

This is the only "definitely lost" record.  The "possibly lost" record is also shown, but it's not the JS engine's fault.  The other 67 loss records are not shown.  I have no idea where the 69 number comes from -- is that some subset of the list of 1,392 "still reachable" blocks?
Multiple leaks from the same code location (as determined by looking at the stack at allocation time) are aggregated into a single "loss record".

The 69 would be 67 (still reachable) + 1 (possibly lost) + 1 (definitely lost), I think.
(Reporter)

Updated

10 years ago
Keywords: testcase
FWIW, I can't reproduce this with revision 393a83c4c7a2.
(Reporter)

Comment 5

9 years ago
WFM
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.