Nathan Froyd [:froydnj] Reporter
	Description • 8 years ago

Saw this in a recent DMD run on 64-bit Windows:

Unreported {
  3 blocks in heap block record 5 of 5,388
  385,024 bytes (375,352 requested / 9,672 slop)
  Individual block sizes: 311,296; 57,344; 16,384
  0.45% of the heap (4.53% cumulative)
  1.43% of unreported (14.44% cumulative)
  Allocated at {
    #01: nsTArray_base<nsTArrayInfallibleAllocator,nsTArray_CopyWithMemutils>::EnsureCapacity<nsTArrayFallibleAllocator> (c:\m-c\obj-dmd64\dist\include\nstarray-inl.h:137)
    #02: nsTArray_base<nsTArrayInfallibleAllocator,nsTArray_CopyWithMemutils>::InsertSlotsAt<nsTArrayFallibleAllocator> (c:\m-c\obj-dmd64\dist\include\nstarray-inl.h:289)
    #03: nsTArray_Impl<mozilla::safebrowsing::SafebrowsingHash<32,mozilla::safebrowsing::CompletionComparator>,nsTArrayInfallibleAllocator>::SetLength<nsTArrayFallibleAllocator> (c:\m-c\obj-dmd64\dist\include\nstarray.h:1766)
    #04: mozilla::safebrowsing::ReadTArray<mozilla::safebrowsing::SafebrowsingHash<32,mozilla::safebrowsing::CompletionComparator>,nsTArrayInfallibleAllocator> (c:\m-c\toolkit\components\url-classifier\entries.h:281)
    #05: mozilla::safebrowsing::LookupCache::ReadCompletions (c:\m-c\toolkit\components\url-classifier\lookupcache.cpp:352)
    #06: mozilla::safebrowsing::LookupCache::Open (c:\m-c\toolkit\components\url-classifier\lookupcache.cpp:99)
    #07: mozilla::safebrowsing::Classifier::GetLookupCache (c:\m-c\toolkit\components\url-classifier\classifier.cpp:701)
    #08: mozilla::safebrowsing::Classifier::RegenActiveTables (c:\m-c\toolkit\components\url-classifier\classifier.cpp:402)
    #09: mozilla::safebrowsing::Classifier::Open (c:\m-c\toolkit\components\url-classifier\classifier.cpp:150)
    #10: nsUrlClassifierDBServiceWorker::OpenDb (c:\m-c\toolkit\components\url-classifier\nsurlclassifierdbservice.cpp:737)
    #11: nsRunnableMethodImpl<void (__cdecl mozilla::dom::SynthStreamListener::*)(void) __ptr64,1>::Run (c:\m-c\obj-dmd64\dist\include\nsthreadutils.h:872)
    #12: nsThread::ProcessNextEvent (c:\m-c\xpcom\threads\nsthread.cpp:1018)
    #13: NS_ProcessNextEvent (c:\m-c\xpcom\glue\nsthreadutils.cpp:297)
    #14: mozilla::ipc::MessagePumpForNonMainThreads::Run (c:\m-c\ipc\glue\messagepump.cpp:326)
    #15: MessageLoop::RunHandler (c:\m-c\ipc\chromium\src\base\message_loop.cc:228)
    #16: MessageLoop::Run (c:\m-c\ipc\chromium\src\base\message_loop.cc:202)
    #17: nsThread::ThreadFunc (c:\m-c\xpcom\threads\nsthread.cpp:413)
    #18: _PR_NativeRunThread (c:\m-c\nsprpub\pr\src\threads\combined\pruthr.c:419)
    #19: pr_root (c:\m-c\nsprpub\pr\src\md\windows\w95thred.c:96)
    #20: beginthreadex[MSVCR120 +0x24f7f]
    #21: endthreadex[MSVCR120 +0x25126]
    #22: BaseThreadInitThunk[KERNEL32 +0x13d2]
    #23: RtlUserThreadStart[ntdll +0x15454]
  }
}

A couple hundred K seems worthwhile to be recording in about:memory.

	Nicholas Nethercote [inactive]
	Comment 1 • 8 years ago

I've seen this too. It's in a worker, though, which complicates things :/

	Gian-Carlo Pascutto [:gcp]
	Comment 2 • 8 years ago

This used to be essentially nothing (like 4 x 32 byte completions at most), but then Tracking Protection started using Completions exclusively :-/

	Gian-Carlo Pascutto [:gcp]
	Comment 3 • 8 years ago

On a related note, the telemetry for Completions also predates Tracking Protection and hence doesn't have a useful range. 

https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/Histograms.json#3247