Re: [webkit-dev] Memory leak tracking in WebKit

[Said Abou-Hallawa]

This seems to be a reference cycle between SVGAnimatedListPropertyTearOff and 
SVGListPropertyTearOff. In SVGAnimatedListPropertyTearOff::animVal(), m_animVal 
is assigned to a new Ref but this new Ref increments 
the refcount of this. This looks similar to 
https://bugs.webkit.org/show_bug.cgi?id=151810.

> On Jan 5, 2016, at 2:19 PM, Vienneau, Christopher  wrote:
> 
> Thanks for suggesting that Simon, I’ve now opened the bug:
> https://bugs.webkit.org/show_bug.cgi?id=152759 
> <https://bugs.webkit.org/show_bug.cgi?id=152759>
>  
> Chris
>  
> From: simon.fra...@apple.com [mailto:simon.fra...@apple.com] 
> Sent: Tuesday, January 05, 2016 12:09 PM
> To: Vienneau, Christopher 
> Cc: WebKit Development 
> Subject: Re: [webkit-dev] Memory leak tracking in WebKit
>  
> This sounds like a bug that would affect all WebKit ports. Can you file a 
> bugs.webkit.org <http://bugs.webkit.org/> bug, and continue investigation 
> there?
>  
> Simon
>  
> On Jan 5, 2016, at 12:03 PM, Vienneau, Christopher  <mailto:cvienn...@ea.com>> wrote:
>  
> Hi,
>  
> I’ve resumed the memory leak tracking I was doing last year, I have some more 
> details to share, hopefully you’ll be able to suggest how I might fix it.  
> The source of the leak appears to come from the below callstack.  A cache of 
> animation points is being created in SVGAnimatedProperty(SVGElement* 
> contextElement, const QualifiedName& attributeName, AnimatedPropertyType 
> animatedPropertyType), however the destructor for SVGAnimatedProperty is 
> never called.  The passed in contextElement gains a ref when the 
> SVGAnimatedProperty is created, however I’m not seeing a code path where the 
> animation points should be destroyed.  This effects both svg polyline and 
> polygon, and results in leaking the whole page.
>  
> Thanks for any help you can provide,
>  
> Chris Vienneau
>  
>  
> \WebCore\svg\properties\SVGAnimatedProperty.cpp
> SVGAnimatedProperty::SVGAnimatedProperty(SVGElement* contextElement, const 
> QualifiedName& attributeName, AnimatedPropertyType animatedPropertyType)
> : m_contextElement(contextElement)
> , m_attributeName(attributeName)
> , m_animatedPropertyType(animatedPropertyType)
> , m_isAnimating(false)
> , m_isReadOnly(false)
> {
> }
>  
> > 
> > EAWebKitd.dll!WebCore::SVGAnimatedProperty::SVGAnimatedProperty(WebCore::SVGElement
> >  * contextElement, const WebCore::QualifiedName & attributeName, 
> > WebCore::AnimatedPropertyType animatedPropertyType) Line 29
> > C++
> 
> EAWebKitd.dll!WebCore::SVGAnimatedListPropertyTearOff::SVGAnimatedListPropertyTearOff(WebCore::SVGElement
>  * contextElement, const WebCore::QualifiedName & attributeName, 
> WebCore::AnimatedPropertyType animatedPropertyType, WebCore::SVGPointList & 
> values) Line 166 C++
> 
> EAWebKitd.dll!WebCore::SVGAnimatedListPropertyTearOff::create(WebCore::SVGElement
>  * contextElement, const WebCore::QualifiedName & attributeName, 
> WebCore::AnimatedPropertyType animatedPropertyType, WebCore::SVGPointList & 
> values) Line 159 C++
> 
> EAWebKitd.dll!WebCore::SVGAnimatedProperty::lookupOrCreateWrapper,WebCore::SVGPointList>(WebCore::SVGPolyElement
>  * element, const WebCore::SVGPropertyInfo * info, WebCore::SVGPointList & 
> property) Line 57 C++
>
> EAWebKitd.dll!WebCore::SVGPolyElement::lookupOrCreatePointsWrapper(WebCore::SVGElement
>  * contextElement) Line 117C++
>EAWebKitd.dll!WebCore::SVGPolyElement::animatedPoints() Line 
> 130  C++
>
> EAWebKitd.dll!WebCore::updatePathFromPolylineElement(WebCore::SVGElement * 
> element, WebCore::Path & path) Line 106   C++
>
> EAWebKitd.dll!WebCore::updatePathFromGraphicsElement(WebCore::SVGElement * 
> element, WebCore::Path & path) Line 172   C++
>
> EAWebKitd.dll!WebCore::RenderSVGShape::updateShapeFromElement() Line 84   
> C++
>EAWebKitd.dll!WebCore::RenderSVGPath::updateShapeFromElement() 
> Line 48  C++
>EAWebKitd.dll!WebCore::RenderSVGShape::layout() Line 164   C++
>
> EAWebKitd.dll!WebCore::SVGRenderSupport::layoutChildren(WebCore::RenderElement
>  & start, bool selfNeedsLayout) Line 281   C++
>EAWebKitd.dll!WebCore::RenderSVGRoot::layout() Line 181  
> C++
>EAWebKitd.dll!WebCore::RenderElement::layoutIfNeeded() Line 
> 135C++
>EAWebKitd.dll!WebCore::RenderBlockFlow::layoutLineBoxes(bool 
&

Re: [webkit-dev] Memory leak tracking in WebKit

[Vienneau, Christopher]

Thanks for suggesting that Simon, I’ve now opened the bug:
https://bugs.webkit.org/show_bug.cgi?id=152759

Chris

From: simon.fra...@apple.com [mailto:simon.fra...@apple.com]
Sent: Tuesday, January 05, 2016 12:09 PM
To: Vienneau, Christopher 
Cc: WebKit Development 
Subject: Re: [webkit-dev] Memory leak tracking in WebKit

This sounds like a bug that would affect all WebKit ports. Can you file a 
bugs.webkit.org<http://bugs.webkit.org> bug, and continue investigation there?

Simon

On Jan 5, 2016, at 12:03 PM, Vienneau, Christopher 
mailto:cvienn...@ea.com>> wrote:

Hi,

I’ve resumed the memory leak tracking I was doing last year, I have some more 
details to share, hopefully you’ll be able to suggest how I might fix it.  The 
source of the leak appears to come from the below callstack.  A cache of 
animation points is being created in SVGAnimatedProperty(SVGElement* 
contextElement, const QualifiedName& attributeName, AnimatedPropertyType 
animatedPropertyType), however the destructor for SVGAnimatedProperty is never 
called.  The passed in contextElement gains a ref when the SVGAnimatedProperty 
is created, however I’m not seeing a code path where the animation points 
should be destroyed.  This effects both svg polyline and polygon, and results 
in leaking the whole page.

Thanks for any help you can provide,

Chris Vienneau


\WebCore\svg\properties\SVGAnimatedProperty.cpp
SVGAnimatedProperty::SVGAnimatedProperty(SVGElement* contextElement, const 
QualifiedName& attributeName, AnimatedPropertyType animatedPropertyType)
: m_contextElement(contextElement)
, m_attributeName(attributeName)
, m_animatedPropertyType(animatedPropertyType)
, m_isAnimating(false)
, m_isReadOnly(false)
{
}

> 
> EAWebKitd.dll!WebCore::SVGAnimatedProperty::SVGAnimatedProperty(WebCore::SVGElement
>  * contextElement, const WebCore::QualifiedName & attributeName, 
> WebCore::AnimatedPropertyType animatedPropertyType) Line 29C++

EAWebKitd.dll!WebCore::SVGAnimatedListPropertyTearOff::SVGAnimatedListPropertyTearOff(WebCore::SVGElement
 * contextElement, const WebCore::QualifiedName & attributeName, 
WebCore::AnimatedPropertyType animatedPropertyType, WebCore::SVGPointList & 
values) Line 166 C++

EAWebKitd.dll!WebCore::SVGAnimatedListPropertyTearOff::create(WebCore::SVGElement
 * contextElement, const WebCore::QualifiedName & attributeName, 
WebCore::AnimatedPropertyType animatedPropertyType, WebCore::SVGPointList & 
values) Line 159 C++

EAWebKitd.dll!WebCore::SVGAnimatedProperty::lookupOrCreateWrapper,WebCore::SVGPointList>(WebCore::SVGPolyElement
 * element, const WebCore::SVGPropertyInfo * info, WebCore::SVGPointList & 
property) Line 57 C++
   
EAWebKitd.dll!WebCore::SVGPolyElement::lookupOrCreatePointsWrapper(WebCore::SVGElement
 * contextElement) Line 117C++
   EAWebKitd.dll!WebCore::SVGPolyElement::animatedPoints() Line 130 
 C++
   
EAWebKitd.dll!WebCore::updatePathFromPolylineElement(WebCore::SVGElement * 
element, WebCore::Path & path) Line 106   C++
   
EAWebKitd.dll!WebCore::updatePathFromGraphicsElement(WebCore::SVGElement * 
element, WebCore::Path & path) Line 172   C++
   EAWebKitd.dll!WebCore::RenderSVGShape::updateShapeFromElement() 
Line 84   C++
   EAWebKitd.dll!WebCore::RenderSVGPath::updateShapeFromElement() 
Line 48  C++
   EAWebKitd.dll!WebCore::RenderSVGShape::layout() Line 164   C++
   
EAWebKitd.dll!WebCore::SVGRenderSupport::layoutChildren(WebCore::RenderElement 
& start, bool selfNeedsLayout) Line 281   C++
   EAWebKitd.dll!WebCore::RenderSVGRoot::layout() Line 181  C++
   EAWebKitd.dll!WebCore::RenderElement::layoutIfNeeded() Line 135  
  C++
   EAWebKitd.dll!WebCore::RenderBlockFlow::layoutLineBoxes(bool 
relayoutChildren, WebCore::LayoutUnit & repaintLogicalTop, WebCore::LayoutUnit 
& repaintLogicalBottom) Line 1621   C++
   
EAWebKitd.dll!WebCore::RenderBlockFlow::layoutInlineChildren(bool 
relayoutChildren, WebCore::LayoutUnit & repaintLogicalTop, WebCore::LayoutUnit 
& repaintLogicalBottom) Line 652C++
   EAWebKitd.dll!WebCore::RenderBlockFlow::layoutBlock(bool 
relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 484C++
   EAWebKitd.dll!WebCore::RenderBlock::layout() Line 930
  C++
   
EAWebKitd.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & 
child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & 
previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 
712C++
   EAWebKitd.dll!WebCore::RenderBlock

Re: [webkit-dev] Memory leak tracking in WebKit

[Simon Fraser]

This sounds like a bug that would affect all WebKit ports. Can you file a 
bugs.webkit.org bug, and continue investigation there?

Simon

> On Jan 5, 2016, at 12:03 PM, Vienneau, Christopher  wrote:
> 
> Hi,
>  
> I’ve resumed the memory leak tracking I was doing last year, I have some more 
> details to share, hopefully you’ll be able to suggest how I might fix it.  
> The source of the leak appears to come from the below callstack.  A cache of 
> animation points is being created in SVGAnimatedProperty(SVGElement* 
> contextElement, const QualifiedName& attributeName, AnimatedPropertyType 
> animatedPropertyType), however the destructor for SVGAnimatedProperty is 
> never called.  The passed in contextElement gains a ref when the 
> SVGAnimatedProperty is created, however I’m not seeing a code path where the 
> animation points should be destroyed.  This effects both svg polyline and 
> polygon, and results in leaking the whole page.
>  
> Thanks for any help you can provide,
>  
> Chris Vienneau
>  
>  
> \WebCore\svg\properties\SVGAnimatedProperty.cpp
> SVGAnimatedProperty::SVGAnimatedProperty(SVGElement* contextElement, const 
> QualifiedName& attributeName, AnimatedPropertyType animatedPropertyType)
> : m_contextElement(contextElement)
> , m_attributeName(attributeName)
> , m_animatedPropertyType(animatedPropertyType)
> , m_isAnimating(false)
> , m_isReadOnly(false)
> {
> }
>  
> > 
> > EAWebKitd.dll!WebCore::SVGAnimatedProperty::SVGAnimatedProperty(WebCore::SVGElement
> >  * contextElement, const WebCore::QualifiedName & attributeName, 
> > WebCore::AnimatedPropertyType animatedPropertyType) Line 29
> > C++
> 
> EAWebKitd.dll!WebCore::SVGAnimatedListPropertyTearOff::SVGAnimatedListPropertyTearOff(WebCore::SVGElement
>  * contextElement, const WebCore::QualifiedName & attributeName, 
> WebCore::AnimatedPropertyType animatedPropertyType, WebCore::SVGPointList & 
> values) Line 166 C++
> 
> EAWebKitd.dll!WebCore::SVGAnimatedListPropertyTearOff::create(WebCore::SVGElement
>  * contextElement, const WebCore::QualifiedName & attributeName, 
> WebCore::AnimatedPropertyType animatedPropertyType, WebCore::SVGPointList & 
> values) Line 159 C++
> 
> EAWebKitd.dll!WebCore::SVGAnimatedProperty::lookupOrCreateWrapper,WebCore::SVGPointList>(WebCore::SVGPolyElement
>  * element, const WebCore::SVGPropertyInfo * info, WebCore::SVGPointList & 
> property) Line 57 C++
>
> EAWebKitd.dll!WebCore::SVGPolyElement::lookupOrCreatePointsWrapper(WebCore::SVGElement
>  * contextElement) Line 117C++
>EAWebKitd.dll!WebCore::SVGPolyElement::animatedPoints() Line 
> 130  C++
>
> EAWebKitd.dll!WebCore::updatePathFromPolylineElement(WebCore::SVGElement * 
> element, WebCore::Path & path) Line 106   C++
>
> EAWebKitd.dll!WebCore::updatePathFromGraphicsElement(WebCore::SVGElement * 
> element, WebCore::Path & path) Line 172   C++
>
> EAWebKitd.dll!WebCore::RenderSVGShape::updateShapeFromElement() Line 84   
> C++
>EAWebKitd.dll!WebCore::RenderSVGPath::updateShapeFromElement() 
> Line 48  C++
>EAWebKitd.dll!WebCore::RenderSVGShape::layout() Line 164   C++
>
> EAWebKitd.dll!WebCore::SVGRenderSupport::layoutChildren(WebCore::RenderElement
>  & start, bool selfNeedsLayout) Line 281   C++
>EAWebKitd.dll!WebCore::RenderSVGRoot::layout() Line 181  
> C++
>EAWebKitd.dll!WebCore::RenderElement::layoutIfNeeded() Line 
> 135C++
>EAWebKitd.dll!WebCore::RenderBlockFlow::layoutLineBoxes(bool 
> relayoutChildren, WebCore::LayoutUnit & repaintLogicalTop, 
> WebCore::LayoutUnit & repaintLogicalBottom) Line 1621   C++
>
> EAWebKitd.dll!WebCore::RenderBlockFlow::layoutInlineChildren(bool 
> relayoutChildren, WebCore::LayoutUnit & repaintLogicalTop, 
> WebCore::LayoutUnit & repaintLogicalBottom) Line 652C++
>EAWebKitd.dll!WebCore::RenderBlockFlow::layoutBlock(bool 
> relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 484C++
>EAWebKitd.dll!WebCore::RenderBlock::layout() Line 930  
> C++
>
> EAWebKitd.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & 
> child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit 
> & previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) 
> Line 712C++
>
> EAWebKitd.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool 
> relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 633   
>  C++
>EAWebKitd.dll!WebCore::RenderBlockFlow::layoutBlock(bool 
> relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 488C++
>

Re: [webkit-dev] Memory leak tracking in WebKit

[Vienneau, Christopher]

Hi,

I’ve resumed the memory leak tracking I was doing last year, I have some more 
details to share, hopefully you’ll be able to suggest how I might fix it.  The 
source of the leak appears to come from the below callstack.  A cache of 
animation points is being created in SVGAnimatedProperty(SVGElement* 
contextElement, const QualifiedName& attributeName, AnimatedPropertyType 
animatedPropertyType), however the destructor for SVGAnimatedProperty is never 
called.  The passed in contextElement gains a ref when the SVGAnimatedProperty 
is created, however I’m not seeing a code path where the animation points 
should be destroyed.  This effects both svg polyline and polygon, and results 
in leaking the whole page.

Thanks for any help you can provide,

Chris Vienneau


\WebCore\svg\properties\SVGAnimatedProperty.cpp
SVGAnimatedProperty::SVGAnimatedProperty(SVGElement* contextElement, const 
QualifiedName& attributeName, AnimatedPropertyType animatedPropertyType)
: m_contextElement(contextElement)
, m_attributeName(attributeName)
, m_animatedPropertyType(animatedPropertyType)
, m_isAnimating(false)
, m_isReadOnly(false)
{
}

> 
> EAWebKitd.dll!WebCore::SVGAnimatedProperty::SVGAnimatedProperty(WebCore::SVGElement
>  * contextElement, const WebCore::QualifiedName & attributeName, 
> WebCore::AnimatedPropertyType animatedPropertyType) Line 29C++

EAWebKitd.dll!WebCore::SVGAnimatedListPropertyTearOff::SVGAnimatedListPropertyTearOff(WebCore::SVGElement
 * contextElement, const WebCore::QualifiedName & attributeName, 
WebCore::AnimatedPropertyType animatedPropertyType, WebCore::SVGPointList & 
values) Line 166 C++

EAWebKitd.dll!WebCore::SVGAnimatedListPropertyTearOff::create(WebCore::SVGElement
 * contextElement, const WebCore::QualifiedName & attributeName, 
WebCore::AnimatedPropertyType animatedPropertyType, WebCore::SVGPointList & 
values) Line 159 C++

EAWebKitd.dll!WebCore::SVGAnimatedProperty::lookupOrCreateWrapper,WebCore::SVGPointList>(WebCore::SVGPolyElement
 * element, const WebCore::SVGPropertyInfo * info, WebCore::SVGPointList & 
property) Line 57 C++
   
EAWebKitd.dll!WebCore::SVGPolyElement::lookupOrCreatePointsWrapper(WebCore::SVGElement
 * contextElement) Line 117C++
   EAWebKitd.dll!WebCore::SVGPolyElement::animatedPoints() Line 130 
 C++
   
EAWebKitd.dll!WebCore::updatePathFromPolylineElement(WebCore::SVGElement * 
element, WebCore::Path & path) Line 106   C++
   
EAWebKitd.dll!WebCore::updatePathFromGraphicsElement(WebCore::SVGElement * 
element, WebCore::Path & path) Line 172   C++
   EAWebKitd.dll!WebCore::RenderSVGShape::updateShapeFromElement() 
Line 84   C++
   EAWebKitd.dll!WebCore::RenderSVGPath::updateShapeFromElement() 
Line 48  C++
   EAWebKitd.dll!WebCore::RenderSVGShape::layout() Line 164   C++
   
EAWebKitd.dll!WebCore::SVGRenderSupport::layoutChildren(WebCore::RenderElement 
& start, bool selfNeedsLayout) Line 281   C++
   EAWebKitd.dll!WebCore::RenderSVGRoot::layout() Line 181  C++
   EAWebKitd.dll!WebCore::RenderElement::layoutIfNeeded() Line 135  
  C++
   EAWebKitd.dll!WebCore::RenderBlockFlow::layoutLineBoxes(bool 
relayoutChildren, WebCore::LayoutUnit & repaintLogicalTop, WebCore::LayoutUnit 
& repaintLogicalBottom) Line 1621   C++
   
EAWebKitd.dll!WebCore::RenderBlockFlow::layoutInlineChildren(bool 
relayoutChildren, WebCore::LayoutUnit & repaintLogicalTop, WebCore::LayoutUnit 
& repaintLogicalBottom) Line 652C++
   EAWebKitd.dll!WebCore::RenderBlockFlow::layoutBlock(bool 
relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 484C++
   EAWebKitd.dll!WebCore::RenderBlock::layout() Line 930
  C++
   
EAWebKitd.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & 
child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & 
previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 
712C++
   EAWebKitd.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool 
relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 633 
   C++
   EAWebKitd.dll!WebCore::RenderBlockFlow::layoutBlock(bool 
relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 488C++
   EAWebKitd.dll!WebCore::RenderBlock::layout() Line 930
  C++
   
EAWebKitd.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & 
child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & 
previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 
712C++
   EAWebKitd.dll!WebCore::RenderBlockFlow:

Re: [webkit-dev] Memory leak tracking in WebKit

[Myles C. Maxfield]

I've got a few questions/statements about this:

1. What makes you think that CSSParser::parseFontFaceSource() is the culprit? 
Which memory instrumentation tools are you using?
2. Font::platformInit() is the function where we start populating all our 
internal font caches. For example, we start creating and populating GlyphPages 
here. It makes sense that it should allocate some memory.
3. Platform fonts are quite heavyweight objects; I would expect these to cost 
more than the work being done in Font::platformInit(). These are allocated in 
FontCache::createFontPlatformData().

If you are able; it might be insightful to take a stack snapshot at every 
memory allocation and aggregate based on the allocation size and the top few 
frames of the stack. With this information, we can try to figure out what the 
memory is being used for, and where it should be released. Then we could try to 
debug why it isn't being released.

> On Nov 30, 2015, at 5:10 PM, Vienneau, Christopher  wrote:
> 
> Hi,
>  
> I’ve still been tracking memory leaks in our application, and I think I have 
> a good test scenario to share. 
>  
> In our application we found that a lot of memory would be held onto when 
> visiting this particular site:
> http://answers.ea.com 
> In a loop we visit this site, and a simple html page that consists of a list 
> of test urls found on the local hard drive.
> Our in built memory tools suggest a leak is coming largely from  
> CSSParser::parseFontFaceSrc(), though admittedly I’ve changed my top suspects 
> from time to time.  I think this item is showing as a large leak due to the 
> inclusion of the font in the css on the answers.ea.com 
>  page, but perhaps there are more smaller items being 
> leaked which is just less obvious (the font is large).
>  
> I’ve reproduce the scenario in the WinCairo test application, based on 
> 188436.  I built in a quick and hacky soak mechanism to conduct the test, 
> perhaps there are better tools I’m not aware of.  I’ve attached the source 
> changes to this mail:
> Source/WebKit/win/WebKitMessageLoop.cpp
> Tools/WinLauncher/Common.cpp
>  
> I can see the memory of the WinLauncher process grow over time, here is an 
> example of the memory usage as seen from the windows task manager over time:
> DurationMemory (reported by windows)
> 0m  155MB
> 13m   178MB
> 23m   199MB
> 36m   219MB  
> 53m   247MB
> 1h4m 259MB
> 1h23m  277MB
> After about an 1h30m, WinLauncher crashes, at the end of the mail is the 
> basic debug data that was available. 
>  
> I’m not sure if the crash is related to the memory leak I’m experiencing, or 
> if it’s an unrelated issue.  Since we’re a few months older from tip I’m 
> wondering if anyone has any recent insights to share on this memory leak 
> scenario? I haven’t identified anything in the change logs, but perhaps there 
> is there something already addressing this?  Does the same issue occur at tip?
>  
> Any feedback is appreciated,
>  
> Thanks
>  
> Chris Vienneau
>  
>  
>  
>  
> + this 0x784be130 
> {m_fontMetrics={m_unitsPerEm=1000 m_ascent=0.0 m_descent=0.0 
> ...} ...} WebCore::Font *
> ascent   0.0   float
> dc   Variable is optimized away and 
> not available. 
> + extents {x_bearing=0.0 
> y_bearing=2.840573810841e-316#DEN width=1.197610077640e-309#DEN ...} 
> cairo_text_extents_t
> metricsMultiplier 
> 0.031250  const double
> faceName   Variable is optimized away 
> and not available. 
> descent52852716.0  
> float
> xHeight Variable is optimized away and not 
> available. 
> + textMetrics{tmHeight=0 tmAscent=0 
> tmDescent=1691286912 ...} tagTEXTMETRICW
> lineGap 63069964.0  float
> scaledFont  0x6477fc00 {...}  
>  _cairo_scaled_font *
> faceLength 0  int
>  
>  
> > WebKit.dll!WebCore::Font::platformInit() Line 82 C++
>WebKit.dll!WebCore::Font::Font(const WebCore::FontPlatformData 
> & platformData, bool isCustomFont, bool isLoading, bool 
> isTextOrientationFallback) Line 80   C++
>WebKit.dll!WebCore::CachedFont::createFont(const 
> WebCore::FontDescription & fontDescription, const WTF::AtomicString & 
> __formal, bool syntheticBold, bool syntheticItalic, bool __formal) Line 126   
>  C+

Re: [webkit-dev] Memory leak tracking in WebKit

[Vienneau, Christopher]

Hi,

I've still been tracking memory leaks in our application, and I think I have a 
good test scenario to share.

In our application we found that a lot of memory would be held onto when 
visiting this particular site:
http://answers.ea.com
In a loop we visit this site, and a simple html page that consists of a list of 
test urls found on the local hard drive.
Our in built memory tools suggest a leak is coming largely from  
CSSParser::parseFontFaceSrc(), though admittedly I've changed my top suspects 
from time to time.  I think this item is showing as a large leak due to the 
inclusion of the font in the css on the answers.ea.com page, but perhaps there 
are more smaller items being leaked which is just less obvious (the font is 
large).

I've reproduce the scenario in the WinCairo test application, based on 188436.  
I built in a quick and hacky soak mechanism to conduct the test, perhaps there 
are better tools I'm not aware of.  I've attached the source changes to this 
mail:
Source/WebKit/win/WebKitMessageLoop.cpp
Tools/WinLauncher/Common.cpp

I can see the memory of the WinLauncher process grow over time, here is an 
example of the memory usage as seen from the windows task manager over time:
DurationMemory (reported by windows)
0m  155MB
13m   178MB
23m   199MB
36m   219MB
53m   247MB
1h4m 259MB
1h23m  277MB
After about an 1h30m, WinLauncher crashes, at the end of the mail is the basic 
debug data that was available.

I'm not sure if the crash is related to the memory leak I'm experiencing, or if 
it's an unrelated issue.  Since we're a few months older from tip I'm wondering 
if anyone has any recent insights to share on this memory leak scenario? I 
haven't identified anything in the change logs, but perhaps there is there 
something already addressing this?  Does the same issue occur at tip?

Any feedback is appreciated,

Thanks

Chris Vienneau




+ this 0x784be130 
{m_fontMetrics={m_unitsPerEm=1000 m_ascent=0.0 m_descent=0.0 
...} ...} WebCore::Font *
ascent   0.0   float
dc   Variable is optimized away and not 
available.
+ extents {x_bearing=0.0 
y_bearing=2.840573810841e-316#DEN width=1.197610077640e-309#DEN ...} 
cairo_text_extents_t
metricsMultiplier 
0.031250  const double
faceName   Variable is optimized away 
and not available.
descent52852716.0  float
xHeight Variable is optimized away and not 
available.
+ textMetrics{tmHeight=0 tmAscent=0 
tmDescent=1691286912 ...} tagTEXTMETRICW
lineGap 63069964.0  float
scaledFont  0x6477fc00 {...}
   _cairo_scaled_font *
faceLength 0  int


> WebKit.dll!WebCore::Font::platformInit() Line 82 C++
   WebKit.dll!WebCore::Font::Font(const WebCore::FontPlatformData & 
platformData, bool isCustomFont, bool isLoading, bool 
isTextOrientationFallback) Line 80   C++
   WebKit.dll!WebCore::CachedFont::createFont(const 
WebCore::FontDescription & fontDescription, const WTF::AtomicString & __formal, 
bool syntheticBold, bool syntheticItalic, bool __formal) Line 126   
 C++
   WebKit.dll!WebCore::CSSFontFaceSource::font(const 
WebCore::FontDescription & fontDescription, bool syntheticBold, bool 
syntheticItalic, WebCore::CSSFontSelector * fontSelector) Line 138 C++
   WebKit.dll!WebCore::CSSFontFace::font(const 
WebCore::FontDescription & fontDescription, bool syntheticBold, bool 
syntheticItalic) Line 127 C++
   WebKit.dll!WebCore::CSSSegmentedFontFace::fontRanges(const 
WebCore::FontDescription & fontDescription) Line 130 C++
   WebKit.dll!WebCore::CSSFontSelector::fontRangesForFamily(const 
WebCore::FontDescription & fontDescription, const WTF::AtomicString & 
familyName) Line 474   C++
   WebKit.dll!WebCore::realizeNextFallback(const 
WebCore::FontDescription & description, unsigned int & index, 
WebCore::FontSelector * fontSelector) Line 90C++
   
WebKit.dll!WebCore::FontCascadeFonts::realizeFallbackRangesAt(const 
WebCore::FontDescription & description, unsigned int index) Line 114
   C++
   WebKit.dll!WebCore::FontCascadeFonts::determinePitch(const 
WebCore::FontDescription & description) Line 64  C++

WebKit.dll!WebCore::BreakingContext::handleText(WTF:

Re: [webkit-dev] Memory leak tracking in WebKit

[Vienneau, Christopher]

To add some more information to this, the allocation that seems to have the 
largest delta amount of allocations between test iterations is:
\wtf\local\wtf\hashtable.h(1248): 
WTF::HashTable,WTF::KeyValuePair,JSC::VariableEnvironmentEntry>,WTF::KeyValuePairKeyExtractor,JSC::VariableEnvironmentEntry>
 
>,JSC::IdentifierRepHash,WTF::HashMap,JSC::VariableEnvironmentEntry,JSC::IdentifierRepHash,WTF::HashTraits
 
>,JSC::VariableEnvironmentEntryHashTraits>::KeyValuePairTraits,WTF::HashTraits
 > 
>::HashTable,WTF::KeyValuePair,JSC::VariableEnvironmentEntry>,WTF::KeyValuePairKeyExtractor,JSC::VariableEnvironmentEntry>
 
>,JSC::IdentifierRepHash,WTF::HashMap,JSC::VariableEnvironmentEntry,JSC::IdentifierRepHash,WTF::HashTraits
 
>,JSC::VariableEnvironmentEntryHashTraits>::KeyValuePairTraits,WTF::HashTraits
 > > + 153
\javascriptcore\local\javascriptcore\parser\parser.cpp(1347): 
JSC::Parser >::parseTryStatement + 
1984
\javascriptcore\local\javascriptcore\parser\parser.cpp(1480): 
JSC::Parser >::parseStatement + 671
\javascriptcore\local\javascriptcore\parser\parser.cpp(497): 
JSC::Parser 
>::parseStatementListItem + 100
\javascriptcore\local\javascriptcore\parser\parser.cpp(379): 
JSC::Parser >::parseSourceElements + 
745
\javascriptcore\local\javascriptcore\parser\parser.cpp(1406): 
JSC::Parser >::parseBlockStatement + 
741
\javascriptcore\local\javascriptcore\parser\parser.cpp(1433): 
JSC::Parser >::parseStatement + 179
\javascriptcore\local\javascriptcore\parser\parser.cpp(497): 
JSC::Parser 
>::parseStatementListItem + 100
\javascriptcore\local\javascriptcore\parser\parser.cpp(379): 
JSC::Parser >::parseSourceElements + 
171
\javascriptcore\local\javascriptcore\parser\parser.cpp(277): 
JSC::Parser >::parseInner + 654

To me this likely indicates this is what is leaking, does this bring up any 
ideas for anyone?

Chris

From: Vienneau, Christopher
Sent: Thursday, November 19, 2015 10:25 PM
To: WebKit Development 
Subject: Memory leak tracking in WebKit

Hi,

I'm currently trying to track a leak in our port of WebKit.  If left to soak in 
an automated test, looping over 100 websites, visiting each for 10 seconds, for 
an evening, I'm finding that memory usage goes up to well over a gigabyte 
(eventually crashing).  I know that a lot of things could remain cached but I'm 
calling code very similar to 
MemoryPressureHandler::releaseMemory(Critical::Yes, Synchronous::Yes) before 
checking the memory counters built into our application.  Manually trying to 
reproduce the leak, I find that many pages don't seem to exhibit any 
identifiable increase in memory when; starting from a simple page, clearing the 
cache, visiting the test page, returning to the simple page and finally 
clearing the cache.  I have identified some pages which seem to be causing a 
problem such as cnn.com, when visiting this page it appears I can expect to 
lose 100-500k.

Our current code is based off of 188436:
-Are there any known memory leaks that I should pick up a fix for? (I searched 
but nothing seemed relevant to the current code I have).
-Are there any tools or techniques that can be recommended for identifying a 
leak?  I've been improving our debug features of our memory system, but I've 
been unable to solidly identify where the memory is going.
-I have the WinCairo sample built at the same revision, are there any memory 
tools that can be used with it to identify if the leak exists there too?

Thanks for any suggestions

Chris Vienneau
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Memory leak tracking in WebKit

[Vienneau, Christopher]

Hi,

I'm currently trying to track a leak in our port of WebKit.  If left to soak in 
an automated test, looping over 100 websites, visiting each for 10 seconds, for 
an evening, I'm finding that memory usage goes up to well over a gigabyte 
(eventually crashing).  I know that a lot of things could remain cached but I'm 
calling code very similar to 
MemoryPressureHandler::releaseMemory(Critical::Yes, Synchronous::Yes) before 
checking the memory counters built into our application.  Manually trying to 
reproduce the leak, I find that many pages don't seem to exhibit any 
identifiable increase in memory when; starting from a simple page, clearing the 
cache, visiting the test page, returning to the simple page and finally 
clearing the cache.  I have identified some pages which seem to be causing a 
problem such as cnn.com, when visiting this page it appears I can expect to 
lose 100-500k.

Our current code is based off of 188436:
-Are there any known memory leaks that I should pick up a fix for? (I searched 
but nothing seemed relevant to the current code I have).
-Are there any tools or techniques that can be recommended for identifying a 
leak?  I've been improving our debug features of our memory system, but I've 
been unable to solidly identify where the memory is going.
-I have the WinCairo sample built at the same revision, are there any memory 
tools that can be used with it to identify if the leak exists there too?

Thanks for any suggestions

Chris Vienneau
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev