820244 - New DMD: ~135kb of dark matter in URIs created from stylesheets

Status: NEW

(Core :: General, defect)

Description

[Justin Lebar (not reading bugmail)]

In the main B2G process with the gallery app open (see attachment 690543 [details]), I see:

> Unreported: 3 blocks in block group 12 of 533
>  135,168 bytes (134,217 requested / 951 slop)
>  0.56% of the heap (33.89% cumulative);  1.10% of unreported (66.72% cumulative)
>  Allocated at
>        malloc /Users/jlebar/code/moz/ff-git/src/memory/build/replace_malloc.c:152 (0x4020b2ae libmozglue.so+0x42ae)
>        moz_malloc /Users/jlebar/code/moz/ff-git/src/memory/mozalloc/mozalloc.cpp:65 (0x40e5adf2 libxul.so+0xc37df2)
>        nsStringBuffer::Alloc(unsigned int) /Users/jlebar/code/moz/ff-git/src/xpcom/string/src/nsSubstring.cpp:178 (0x40c7454c libxul.so+0xa5154c)
>        nsACString_internal::MutatePrep(unsigned int, char**, unsigned int*) /Users/jlebar/code/moz/ff-git/src/xpcom/string/src/nsTSubstring.cpp:131 (0x40c745e8 libxul.so+0xa515e8)
>        nsACString_internal::ReplacePrepInternal(unsigned int, unsigned int, unsigned int, unsigned int) /Users/jlebar/code/moz/ff-git/src/xpcom/string/src/nsTSubstring.cpp:166 (0x40c7488a libxul.so+0xa5188a)
>        nsACString_internal::ReplacePrep(unsigned int, unsigned int, unsigned int) /Users/jlebar/code/moz/B2G/objdir-gecko/dist/include/nsTSubstring.h:720 (0x40c7493a libxul.so+0xa5193a)
>        nsACString_internal::Assign(char const*, unsigned int, mozilla::fallible_t const&) /Users/jlebar/code/moz/ff-git/src/xpcom/string/src/nsTSubstring.cpp:311 (0x40c75072 libxul.so+0xa52072)
>        nsACString_internal::Assign(nsACString_internal const&, mozilla::fallible_t const&) /Users/jlebar/code/moz/ff-git/src/xpcom/string/src/nsTSubstring.cpp:387 (0x40c74f0c libxul.so+0xa51f0c)
>        nsACString_internal::Assign(nsACString_internal const&) /Users/jlebar/code/moz/ff-git/src/xpcom/string/src/nsTSubstring.cpp:347 (0x40c74fd0 libxul.so+0xa51fd0)
>        nsSimpleURI::SetPath(nsACString_internal const&) /Users/jlebar/code/moz/ff-git/src/netwerk/base/src/nsSimpleURI.cpp:374 (0x404b5322 libxul.so+0x292322)
>        nsSimpleURI::SetSpec(nsACString_internal const&) /Users/jlebar/code/moz/ff-git/src/netwerk/base/src/nsSimpleURI.cpp:230 (0x404b562e libxul.so+0x29262e)
>  ***   nsDataHandler::NewURI(nsACString_internal const&, char const*, nsIURI*, nsIURI**) /Users/jlebar/code/moz/ff-git/src/netwerk/protocol/data/nsDataHandler.cpp:103 (0x411ec1cc libxul.so+0x2c51cc)
>        nsIOService::NewURI(nsACString_internal const&, char const*, nsIURI*, nsIURI**) /Users/jlebar/code/moz/ff-git/src/netwerk/base/src/nsIOService.cpp:542 (0x404ae7fc libxul.so+0x28b7fc)
>        ~nsCOMPtr /Users/jlebar/code/moz/B2G/objdir-gecko/dist/include/nsCOMPtr.h:453 (0x4062fe1c libxul.so+0x40ce1c)
>        nsCSSValue::StartImageLoad(nsIDocument*) const /Users/jlebar/code/moz/ff-git/src/layout/style/nsCSSValue.cpp:576 (0x41335f5a libxul.so+0x40ef5a)
>        TryToStartImageLoadOnValue /Users/jlebar/code/moz/ff-git/src/layout/style/nsCSSDataBlock.cpp:54 (0x406139a0 libxul.so+0x3f09a0)
>        TryToStartImageLoad /Users/jlebar/code/moz/ff-git/src/layout/style/nsCSSDataBlock.cpp:89 (0x40613a0c libxul.so+0x3f0a0c)
>        TryToStartImageLoad /Users/jlebar/code/moz/ff-git/src/layout/style/nsCSSDataBlock.cpp:78 (0x406139e8 libxul.so+0x3f09e8)
>        nsCSSCompressedDataBlock::MapRuleInfoInto(nsRuleData*) const /Users/jlebar/code/moz/ff-git/src/layout/style/nsCSSDataBlock.cpp:128 (0x40613aa4 libxul.so+0x3f0aa4)
>        mozilla::css::StyleRule::MapRuleInfoInto(nsRuleData*) /Users/jlebar/code/moz/ff-git/src/layout/style/StyleRule.cpp:1448 (0x4062a052 libxul.so+0x407052)
>        nsRuleNode::WalkRuleTree(nsStyleStructID, nsStyleContext*) /Users/jlebar/code/moz/ff-git/src/layout/style/nsRuleNode.cpp:1964 (0x4063ef86 libxul.so+0x41bf86)
>        nsRuleNode::GetStyleBackground(nsStyleContext*, bool) /Users/jlebar/code/moz/ff-git/src/layout/style/nsStyleStructList.h:79 (0x4063fb60 libxul.so+0x41cb60)
>        nsCSSFrameConstructor::ConstructFramesFromItem(nsFrameConstructorState&, nsCSSFrameConstructor::FrameConstructionItemList::Iterator&, nsIFrame*, nsFrameItems&) /Users/jlebar/code/moz/ff-git/src/layout/base/nsCSSFrameConstructor.cpp:5486 (0x4058730e libxul.so+0x36430e)
>        nsCSSFrameConstructor::ConstructFramesFromItemList(nsFrameConstructorState&, nsCSSFrameConstructor::FrameConstructionItemList&, nsIFrame*, nsFrameItems&) /Users/jlebar/code/moz/B2G/objdir-gecko/dist/include/nsError.h:155 (0x40587610 libxul.so+0x364610)

I presume these are data URIs because the 135kb is in only three allocations.  Also, maybe that's what nsDataHandler is doing in the stack.

Comment 1

[Boris Zbarsky [:bzbarsky]]

nsDataHandler is data: URIs, yes.  

I don't believe we report URIs from URI/Image values because they're refcounted and double-counting is very hard to avoid.  :(

Comment 2

[Justin Lebar (not reading bugmail)]

I'm gonna guess that this is related to bug 820940.