Closed Bug 1007434 Opened 10 years ago Closed 8 years ago

The ProfileEntry array created by ThreadProfile::ThreadProfile can be responsible for a lot of dark matter

Categories

(Core :: Gecko Profiler, defect)

x86
macOS
defect
Not set
normal

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.
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
Does this only show up in the profiler is enabled?
No, I didn't invoke the profiler.
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
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
Your stack shows that something from JS is calling nsProfiler::StartProfiler.
(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>
yeah, we start that actor when the toolbox is opened so we can call console.profile/profileEnd() from code.
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.
That sounds good, but we need to fix this leak regardless. :-)
Whiteboard: [MemShrink] → [MemShrink:P2]
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.