The default bug view has changed. See this FAQ.

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

NEW
Unassigned

Status

()

Core
General
4 years ago
4 years ago

People

(Reporter: Justin Lebar (not reading bugmail), Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
ARM
Gonk (Firefox OS)
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink:P2])

(Reporter)

Description

4 years ago
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.
(Reporter)

Updated

4 years ago
Whiteboard: [MemShrink]
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.  :(
Whiteboard: [MemShrink] → [MemShrink:P2]
(Reporter)

Comment 2

4 years ago
I'm gonna guess that this is related to bug 820940.
Depends on: 820940
You need to log in before you can comment on or make changes to this bug.