Closed
Bug 1007434
Opened 10 years ago
Closed 7 years ago
The ProfileEntry array created by ThreadProfile::ThreadProfile can be responsible for a lot of dark matter
Categories
(Core :: Gecko Profiler, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 816598
People
(Reporter: jwatt, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [MemShrink:P2])
It seems the new ProfileEntry created by ThreadProfile::ThreadProfile can be responsible for a substantial chunk of dark matter: https://mxr.mozilla.org/mozilla-central/source/tools/profiler/ProfileEntry.cpp#164 I'm using DMD to find places in SVG that we need to add memory reporters because SVG currently does a very bad job of that. Despite that, this ProfileEntry array is the second biggest source of dark matter in my DMD report, being responsible for 15% of unreported memory. Seems like we need a reporter for it.
Reporter | ||
Comment 1•10 years ago
|
||
Unreported: 1 block in stack trace record 2 of 2,234 9,003,008 bytes (9,000,000 requested / 3,008 slop) 5.79% of the heap (11.61% cumulative); 15.50% of unreported (31.10% cumulative) Allocated at replace_malloc[/Users/jwatt/mozilla/trees/obj/i-debug/dist/lib/libdmd.dylib +0x2A58] 0x1aa58 malloc_impl[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/libmozglue.dylib +0x2260] 0x76260 zone_malloc[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/libmozglue.dylib +0x1AD9] 0x75ad9 malloc_zone_malloc[/usr/lib/system/libsystem_malloc.dylib +0x10868] 0x8936f868 malloc[/usr/lib/system/libsystem_malloc.dylib +0x1127C] 0x8937027c moz_xmalloc[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/libmozalloc.dylib +0x1C85] 0x345c85 ThreadProfile::ThreadProfile(char const*, int, PseudoStack*, int, PlatformData*, bool, void*)[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x381486F] 0x657286f ThreadProfile::ThreadProfile(char const*, int, PseudoStack*, int, PlatformData*, bool, void*)[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x3814768] 0x6572768 TableTicker::RegisterThread(ThreadInfo*)[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x381EC54] 0x657cc54 TableTicker::TableTicker(double, int, char const**, unsigned int, char const**, unsigned int)[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x38225D6] 0x65805d6 TableTicker::TableTicker(double, int, char const**, unsigned int, char const**, unsigned int)[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x381F603] 0x657d603 mozilla_sampler_start(int, double, char const**, unsigned int, char const**, unsigned int)[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x381C44E] 0x657a44e profiler_start(int, int, char const**, unsigned int, char const**, unsigned int)[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x3819289] 0x6577289 nsProfiler::StartProfiler(unsigned int, double, char const**, unsigned int, char const**, unsigned int)[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x3819229] 0x6577229 NS_InvokeByIndex[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x169E19] 0x2ec7e19 CallMethodHelper::Invoke()[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x1F41914] 0x4c9f914 CallMethodHelper::Call()[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x1F35A37] 0x4c93a37 XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x1F148D7] 0x4c728d7 XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x1F16E9B] 0x4c74e9b js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&)[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x50265C5] 0x7d845c5 js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct)[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x4FFA9D3] 0x7d589d3 Interpret(JSContext*, js::RunState&)[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x4FF0B6B] 0x7d4eb6b js::RunScript(JSContext*, js::RunState&)[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x4FE38B9] 0x7d418b9 js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct)[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x4FFAAF3] 0x7d58af3
Comment 2•10 years ago
|
||
Does this only show up in the profiler is enabled?
Reporter | ||
Comment 3•10 years ago
|
||
No, I didn't invoke the profiler.
Reporter | ||
Comment 4•10 years ago
|
||
Actually there are lots of similar stacks. The summary from the "Unreported stack frame records" section of DMD's report says this is actually responsible for 46.26% of the dark matter for my testcase: Unreported: 722 blocks from 25 stack trace records in stack frame record 7 of 7,892 17,862,656 bytes (15,489,000 requested / 2,373,656 slop) 11.48% of the heap; 30.76% of unreported PC is ThreadProfile::ThreadProfile(char const*, int, PseudoStack*, int, PlatformData*, bool, void*)[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x381486F] 0x657286f Unreported: 1 block from 1 stack trace record in stack frame record 46 of 7,892 9,003,008 bytes (9,000,000 requested / 3,008 slop) 5.79% of the heap; 15.50% of unreported PC is ThreadProfile::ThreadProfile(char const*, int, PseudoStack*, int, PlatformData*, bool, void*)[/Users/jwatt/mozilla/trees/obj/i-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x3814768] 0x6572768
Updated•10 years ago
|
Summary: The new ProfileEntry created by ThreadProfile::ThreadProfile can be responsible for a lot of dark matter → The ProfileEntry array created by ThreadProfile::ThreadProfile can be responsible for a lot of dark matter
Comment 5•10 years ago
|
||
Your stack shows that something from JS is calling nsProfiler::StartProfiler.
Comment 6•10 years ago
|
||
(In reply to comment #5) > Your stack shows that something from JS is calling nsProfiler::StartProfiler. devtools? <http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/profiler.js#85>
Comment 7•10 years ago
|
||
yeah, we start that actor when the toolbox is opened so we can call console.profile/profileEnd() from code.
Comment 8•10 years ago
|
||
I think we may be able to lazily initialize the nsIProfiler, instead of immediately on actor instantiation. I was looking into it in bug 879008.
Comment 9•10 years ago
|
||
That sounds good, but we need to fix this leak regardless. :-)
Updated•10 years ago
|
Whiteboard: [MemShrink] → [MemShrink:P2]
Updated•7 years ago
|
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•