[webkit-dev] Memory leak tracking in WebKit
Myles C. Maxfield
mmaxfield at apple.com
Tue Dec 1 16:04:21 PST 2015
Your first 4 stack traces are items which are put into our memory cache, and then held on to for subsequent page loads.
The 5th and 6th stack trace looks like the page is encoding a font into a base-64-encoded data: URI. Our internal representation of CSS (CSSStyleSheet class) is retained by the Document directly (look for m_authorStyleSheets & friends). We don't destroy Documents when you navigate away from them; instead, they are placed into the page cache (so the "back" button is fast).
At any rate, a good first step would probably be to investigate the classes at WebCore/history/PageCache.h and WebCore/loader/cache/MemoryCache.h.
--Myles
> On Dec 1, 2015, at 11:59 AM, Vienneau, Christopher <cvienneau at ea.com> wrote:
>
> Hi Myles,
>
> Thanks for the response, I’ve tried to put as much data as I could about the leak tracking below. Let me know any insights you have regarding where you believe the leak is originating, it seems to me that likely some upper level object is not being released. Also if you notice any flaws in the process used to track the leak, I can attempt to improve this.
>
> >> What makes you think that CSSParser::parseFontFaceSource() is the culprit? Which memory instrumentation tools are you using?
> I’ve been using tools built into our application for analysis. Every allocation and free are logged to a file with some meta data (address, alignment, requested size, actual size, name, callstack). An offline tool processes this log to identify any active allocations, essentially subtracting the free’ed items from the list. Its bucketized based off the meta information, in this case I’ve hashed the callstack addresses together to try and have unique info for each allocations callstack, that means an allocation from a line of code will show up differently in the list if called from someplace else. A test is conducted by performing the below steps:
> 1- Launch the application at testlinks.html
> 2- go to http://answers.ea.com <http://answers.ea.com/>
> 3- go to testlinks.html
> 4- clear the cache, similar to MemoryPressureHandler::releaseMemory(Critical::Yes, Synchronous::Yes)
> 5- save the complete memory log
> 6- repeat steps 2-5 about 6 times
>
> At each iteration we can see our memory use grow (several MB). Note that on some pages a little memory growth is observed, on most no memory growth is observed. For example, I ran a soak iterating betweenhttp://www.webkit.org/perf/sunspider-0.9.1/sunspider-0.9.1/driver.html <http://www.webkit.org/perf/sunspider-0.9.1/sunspider-0.9.1/driver.html> and https://www.webkit.org/perf/sunspider-1.0.2/sunspider-1.0.2/driver.html <https://www.webkit.org/perf/sunspider-1.0.2/sunspider-1.0.2/driver.html> for about a week and saw nill memory growth. While http://answers.ea.com <http://answers.ea.com/> and the 404 from http://thesims.com/en_us/home <http://thesims.com/en_us/home> seem to produce a large leak.
>
> The offline tool is capable of diffing any two logs so we can see the delta in an allocation type. I expect some growth at the start when we initialize and buffers and what not get sized appropriately, so I’ll select the 3rd and 6th log for comparison. Sorting the data by allocation size the top of the list looks like so:
> index
> Callstack hash
> alignment
> requested
> actual
> count
> total
> Delta
> last label
> 29069
> EAWebKit::7ff9af5270a
> 0
> 2805760
> 2805776
> 1
> 2805776
> file:///C:/EAWebKitDemoUTFWin/dev/data/WebPages/QAInternal/test_links.html <file:///C:/EAWebKitDemoUTFWin/dev/data/WebPages/QAInternal/test_links.html>
> 1393090
> EAWebKit::9a6160de
> 0
> 1018137
> 1019872
> 1
> 1019872
> 1
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> 2685982
> EAWebKit::9a6160de
> 0
> 1018137
> 1018160
> 2
> 2036320
> 2
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> 2978256
> EAWebKit::9a6160de
> 0
> 742719
> 745440
> 2
> 1490880
> 3
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> 361390
> EAWebKit::9a6160de
> 0
> 742719
> 742736
> 1
> 742736
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> 2858196
> EAWebKit::9a6160de
> 0
> 370617
> 372704
> 1
> 372704
> 1
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> 1565700
> EAWebKit::9a6160de
> 0
> 370617
> 370640
> 1
> 370640
> 2
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> 241091
> EAWebKit::7ff9a6160de
> 0
> 370617
> 370640
> 1
> 370640
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> 1858772
> EAWebKit::fec447
> 0
> 321182
> 323552
> 2
> 647104
> 2
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> 535055
> EAWebKit::fec447
> 0
> 321182
> 321200
> 1
> 321200
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> 2843994
> EAWebKit::86d391
> 0
> 284812
> 286688
> 1
> 286688
> 1
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> 226563
> EAWebKit::7ff0086d391
> 0
> 284812
> 284832
> 1
> 284832
> 1
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
>
> So the count is the number of that type of allocation identified in log file #3 and the delta is the increase in that type of allocation in log file #6. Let me know if a deeper callstack would be of use, it’s a trade off in size and performance when logging the info. The callstack data I have is:
>
> 29069
> EAWebKit::7ff9af5270a
> 0
> 2805760
> 2805776
> 1
> 2805776
> file:///C:/EAWebKitDemoUTFWin/dev/data/WebPages/QAInternal/test_links.html <file:///C:/EAWebKitDemoUTFWin/dev/data/WebPages/QAInternal/test_links.html>
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webkit\ea\api\eawebkit\source\eawebkitview.cpp(756): EA::WebKit::View::SetSize + 162
>
> 1393090
> EAWebKit::9a6160de
> 0
> 1018137
> 1019872
> 1
> 1019872
> 1
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> 2685982
> EAWebKit::9a6160de
> 0
> 1018137
> 1018160
> 2
> 2036320
> 2
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> 2978256
> EAWebKit::9a6160de
> 0
> 742719
> 745440
> 2
> 1490880
> 3
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> 361390
> EAWebKit::9a6160de
> 0
> 742719
> 742736
> 1
> 742736
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> 2858196
> EAWebKit::9a6160de
> 0
> 370617
> 372704
> 1
> 372704
> 1
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> 1565700
> EAWebKit::9a6160de
> 0
> 370617
> 370640
> 1
> 370640
> 2
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> 1393090
> EAWebKit::9a6160de
> 0
> 1018137
> 1019872
> 1
> 1019872
> 1
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
>
> \dev\eawebkitsupportpackages\wtf\local\wtf\vector.h(1099): WTF::Vector<unsigned char,0,WTF::CrashOnOverflow,16>::reserveCapacity + 57
> \dev\eawebkitsupportpackages\wtf\local\wtf\vector.h(1011): WTF::Vector<unsigned char,0,WTF::CrashOnOverflow,16>::resize + 95
> \dev\webcore\platform\sharedbuffer.cpp(327): WebCore::SharedBuffer::buffer + 46
> \dev\webcore\platform\sharedbuffer.cpp(141): WebCore::SharedBuffer::data + 18
> \dev\webcore\loader\cache\cachedcssstylesheet.cpp(100): WebCore::CachedCSSStyleSheet::finishLoading + 144
> \dev\webcore\loader\subresourceloader.cpp(381): WebCore::SubresourceLoader::didFinishLoading + 120
> \dev\webcore\platform\network\ea\resourcehandlemanagerea.cpp(1200): WebCore::ResourceHandleManager::DataDone + 704
> unknown(0): unknown + 0
> \dev\webcore\platform\network\ea\resourcehandlemanagerea.cpp(788): WebCore::ResourceHandleManager::ProcessJobState + 239
> \dev\webcore\platform\network\ea\resourcehandlemanagerea.cpp(697): WebCore::ResourceHandleManager::ProcessJobs + 113
>
> 241091
> EAWebKit::7ff9a6160de
> 0
> 370617
> 370640
> 1
> 370640
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> \dev\eawebkitsupportpackages\wtf\local\wtf\vector.h(1099): WTF::Vector<unsigned char,0,WTF::CrashOnOverflow,16>::reserveCapacity + 57
> \dev\eawebkitsupportpackages\wtf\local\wtf\vector.h(1011): WTF::Vector<unsigned char,0,WTF::CrashOnOverflow,16>::resize + 95
> \dev\webcore\platform\sharedbuffer.cpp(327): WebCore::SharedBuffer::buffer + 46
> \dev\webcore\platform\sharedbuffer.cpp(141): WebCore::SharedBuffer::data + 18
> \dev\webcore\loader\cache\cachedcssstylesheet.cpp(100): WebCore::CachedCSSStyleSheet::finishLoading + 144
> \dev\webcore\loader\subresourceloader.cpp(381): WebCore::SubresourceLoader::didFinishLoading + 120
> \dev\webcore\platform\network\ea\resourcehandlemanagerea.cpp(1200): WebCore::ResourceHandleManager::DataDone + 704
> \dev\webcore\platform\network\ea\resourcehandlemanagerea.cpp(788): WebCore::ResourceHandleManager::ProcessJobState + 239
> \dev\webcore\platform\network\ea\resourcehandlemanagerea.cpp(697): WebCore::ResourceHandleManager::ProcessJobs + 113
>
> 1858772
> EAWebKit::fec447
> 0
> 321182
> 323552
> 2
> 647104
> 2
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> \dev\eawebkitsupportpackages\wtf\local\wtf\vector.h(1099): WTF::Vector<unsigned char,0,WTF::CrashOnOverflow,16>::reserveCapacity + 57
> \dev\eawebkitsupportpackages\wtf\local\wtf\vector.h(1011): WTF::Vector<unsigned char,0,WTF::CrashOnOverflow,16>::resize + 95
> \dev\webcore\platform\sharedbuffer.cpp(327): WebCore::SharedBuffer::buffer + 46
> \dev\webcore\platform\sharedbuffer.cpp(141): WebCore::SharedBuffer::data + 18
> \dev\webcore\loader\cache\cachedscript.cpp(75): WebCore::CachedScript::script + 75
> \dev\eawebkitsupportpackages\javascriptcore\local\javascriptcore\parser\sourcecode.h(56): JSC::SourceCode::SourceCode + 45
> \dev\webcore\bindings\js\scriptsourcecode.h(56): WebCore::ScriptSourceCode::ScriptSourceCode + 72
> \dev\webcore\html\parser\htmlscriptrunner.cpp(94): WebCore::HTMLScriptRunner::sourceFromPendingScript + 104
> \dev\webcore\html\parser\htmlscriptrunner.cpp(129): WebCore::HTMLScriptRunner::executePendingScriptAndDispatchEvent + 56
> \dev\webcore\html\parser\htmlscriptrunner.cpp(121): WebCore::HTMLScriptRunner::executeParsingBlockingScript + 51
>
> 2843994
> EAWebKit::86d391
> 0
> 284812
> 286688
> 1
> 286688
> 1
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> \dev\eawebkitsupportpackages\wtf\local\wtf\vector.h(1099): WTF::Vector<unsigned char,0,WTF::CrashOnOverflow,16>::reserveCapacity + 57
> \dev\eawebkitsupportpackages\wtf\local\wtf\vector.h(1011): WTF::Vector<unsigned char,0,WTF::CrashOnOverflow,16>::resize + 95
> \dev\webcore\platform\sharedbuffer.cpp(327): WebCore::SharedBuffer::buffer + 46
> \dev\webcore\platform\sharedbuffer.cpp(141): WebCore::SharedBuffer::data + 18
> \dev\webcore\loader\cache\cachedscript.cpp(75): WebCore::CachedScript::script + 75
> \dev\eawebkitsupportpackages\javascriptcore\local\javascriptcore\parser\sourcecode.h(56): JSC::SourceCode::SourceCode + 45
> \dev\webcore\bindings\js\scriptsourcecode.h(56): WebCore::ScriptSourceCode::ScriptSourceCode + 72
> \dev\webcore\html\parser\htmlscriptrunner.cpp(94): WebCore::HTMLScriptRunner::sourceFromPendingScript + 104
> \dev\webcore\html\parser\htmlscriptrunner.cpp(129): WebCore::HTMLScriptRunner::executePendingScriptAndDispatchEvent + 56
> \dev\webcore\html\parser\htmlscriptrunner.cpp(121): WebCore::HTMLScriptRunner::executeParsingBlockingScript + 51
>
> 2843994
> EAWebKit::86d391
> 0
> 284812
> 286688
> 1
> 286688
> 1
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> dev\eawebkitsupportpackages\wtf\local\wtf\text\stringimpl.cpp(247): WTF::StringImpl::createInternal<char16_t> + 69
> dev\eawebkitsupportpackages\wtf\local\wtf\text\stringimpl.cpp(254): WTF::StringImpl::create + 14
> dev\eawebkitsupportpackages\wtf\local\wtf\text\wtfstring.cpp(47): WTF::String::String + 31
> dev\webcore\css\cssparservalues.h(98): WebCore::CSSParserString::operator WTF::String + 67
> dev\webcore\css\cssparser.cpp(6924): WebCore::CSSParser::parseFontFaceSrcURI + 94
> dev\webcore\css\cssparser.cpp(6988): WebCore::CSSParser::parseFontFaceSrc + 128
> dev\webcore\css\cssparser.cpp(2376): WebCore::CSSParser::parseValue + 1442
> demoutfwin\dev\build\win64\eawebkit\dev\cssgrammar.y(1294): cssyyparse + 1185
> dev\webcore\css\cssparser.cpp(461): WebCore::CSSParser::parseSheet + 500
> dev\webcore\css\stylesheetcontents.cpp(318): WebCore::StyleSheetContents::parseAuthorStyleSheet + 799
>
> 226563
> EAWebKit::7ff0086d391
> 0
> 284812
> 284832
> 1
> 284832
> 1
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> \eawebkitsupportpackages\wtf\local\wtf\text\stringimpl.cpp(247): WTF::StringImpl::createInternal<char16_t> + 69
> \eawebkitsupportpackages\wtf\local\wtf\text\stringimpl.cpp(254): WTF::StringImpl::create + 14
> \eawebkitsupportpackages\wtf\local\wtf\text\wtfstring.cpp(47): WTF::String::String + 31
> \webcore\css\cssparservalues.h(98): WebCore::CSSParserString::operator WTF::String + 67
> \webcore\css\cssparser.cpp(6924): WebCore::CSSParser::parseFontFaceSrcURI + 94
> \webcore\css\cssparser.cpp(6988): WebCore::CSSParser::parseFontFaceSrc + 128
> \webcore\css\cssparser.cpp(2376): WebCore::CSSParser::parseValue + 1442
> outfwin\dev\build\win64\eawebkit\dev\cssgrammar.y(1294): cssyyparse + 1185
> \webcore\css\cssparser.cpp(461): WebCore::CSSParser::parseSheet + 500
> \webcore\css\stylesheetcontents.cpp(318): WebCore::StyleSheetContents::parseAuthorStyleSheet + 799
>
> The common thing I see from these callstacks is that css related data seems to be what is growing, while it is not particular to the css font, the font appears to be a large part of it. Understanding what is happening there may apply to the rest of it.
>
> If I instead sort by delta count, we can see the small allocations that have increased a lot:
> index
> Callstack hash
> alignment
> requested
> actual
> count
> total
> Delta
> last label
> 1482020
> EAWebKit::7ff9a83f860
> 0
> 24
> 32
> 5953
> 190496
> 6053
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> 2802991
> EAWebKit::7ff003ec20e
> 0
> 18
> 32
> 5362
> 171584
> 5863
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
> 2746268
> EAWebKit::7ff00ff0d31
> 0
> 80
> 96
> 3217
> 308832
> 3252
> http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English <http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English>
>
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\css\cssparser.cpp(12299): WebCore::CSSParser::createStyleRule + 111
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkitdemoutfwin\dev\build\win64\eawebkit\dev\cssgrammar.y(832): cssyyparse + -912
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\css\cssparser.cpp(461): WebCore::CSSParser::parseSheet + 500
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\css\stylesheetcontents.cpp(318): WebCore::StyleSheetContents::parseAuthorStyleSheet + 799
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\html\htmllinkelement.cpp(352): WebCore::HTMLLinkElement::setCSSStyleSheet + 858
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\loader\cache\cachedcssstylesheet.cpp(114): WebCore::CachedCSSStyleSheet::checkNotify + 318
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\loader\cache\cachedcssstylesheet.cpp(104): WebCore::CachedCSSStyleSheet::finishLoading + 266
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\loader\subresourceloader.cpp(381): WebCore::SubresourceLoader::didFinishLoading + 120
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\platform\network\ea\resourcehandlemanagerea.cpp(1200): WebCore::ResourceHandleManager::DataDone + 704
> unknown(0): unknown + 0
>
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\css\styleproperties.cpp(59): WebCore::ImmutableStyleProperties::create + 49
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\css\cssparser.cpp(1591): WebCore::CSSParser::createStyleProperties + 454
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\css\cssparser.cpp(12299): WebCore::CSSParser::createStyleRule + 84
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkitdemoutfwin\dev\build\win64\eawebkit\dev\cssgrammar.y(832): cssyyparse + -912
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\css\cssparser.cpp(461): WebCore::CSSParser::parseSheet + 500
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\css\stylesheetcontents.cpp(318): WebCore::StyleSheetContents::parseAuthorStyleSheet + 799
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\html\htmllinkelement.cpp(352): WebCore::HTMLLinkElement::setCSSStyleSheet + 858
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\loader\cache\cachedcssstylesheet.cpp(114): WebCore::CachedCSSStyleSheet::checkNotify + 318
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\loader\cache\cachedcssstylesheet.cpp(104): WebCore::CachedCSSStyleSheet::finishLoading + 266
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\loader\subresourceloader.cpp(381): WebCore::SubresourceLoader::didFinishLoading + 120
>
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\css\cssselectorlist.cpp(64): WebCore::CSSSelectorList::adoptSelectorVector + 146
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\css\cssparser.cpp(12301): WebCore::CSSParser::createStyleRule + 254
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkitdemoutfwin\dev\build\win64\eawebkit\dev\cssgrammar.y(832): cssyyparse + -912
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\css\cssparser.cpp(461): WebCore::CSSParser::parseSheet + 500
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\css\stylesheetcontents.cpp(318): WebCore::StyleSheetContents::parseAuthorStyleSheet + 799
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\html\htmllinkelement.cpp(352): WebCore::HTMLLinkElement::setCSSStyleSheet + 858
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\loader\cache\cachedcssstylesheet.cpp(114): WebCore::CachedCSSStyleSheet::checkNotify + 318
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\loader\cache\cachedcssstylesheet.cpp(104): WebCore::CachedCSSStyleSheet::finishLoading + 266
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\loader\subresourceloader.cpp(381): WebCore::SubresourceLoader::didFinishLoading + 120
> c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\platform\network\ea\resourcehandlemanagerea.cpp(1200): WebCore::ResourceHandleManager::DataDone + 704
>
> 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.
> The leak appears to be limitless, if I let it run overnight it gets up into the GB. WinCairo has instead crashed after running the soak for over an hour, but it does seem it is experiencing memory growth too.
>
> From: mmaxfield at apple.com [mailto:mmaxfield at apple.com]
> Sent: Monday, November 30, 2015 5:43 PM
> To: Vienneau, Christopher <cvienneau at ea.com>
> Cc: WebKit Development <webkit-dev at lists.webkit.org>
> Subject: Re: [webkit-dev] Memory leak tracking in WebKit
>
> 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 <cvienneau at ea.com <mailto:cvienneau at ea.com>> 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 <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 <http://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:
> Duration Memory (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 0x00000000784be130 {m_fontMetrics={m_unitsPerEm=1000 m_ascent=0.000000000 m_descent=0.000000000 ...} ...} WebCore::Font *
> ascent 0.000000000 float
> dc Variable is optimized away and not available.
> + extents {x_bearing=0.00000000000000000 y_bearing=2.840573810841e-316#DEN width=1.197610077640e-309#DEN ...} cairo_text_extents_t
> metricsMultiplier 0.031250000000000000 const double
> faceName Variable is optimized away and not available.
> descent 52852716.0 float
> xHeight Variable is optimized away and not available.
> + textMetrics {tmHeight=0 tmAscent=0 tmDescent=1691286912 ...} tagTEXTMETRICW
> lineGap 63069964.0 float
> scaledFont 0x000000006477fc00 {...} _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 90 C++
> 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::Vector<WebCore::WordMeasurement,64,WTF::CrashOnOverflow,16> & wordMeasurements, bool & hyphenated, unsigned int & consecutiveHyphenatedLines) Line 731 C++
> WebKit.dll!WebCore::LineBreaker::nextLineBreak(WebCore::BidiResolver<WebCore::InlineIterator,WebCore::BidiRun> & resolver, WebCore::LineInfo & lineInfo, WebCore::RenderTextInfo & renderTextInfo, WebCore::FloatingObject * lastFloatFromPreviousLine, unsigned int consecutiveHyphenatedLines, WTF::Vector<WebCore::WordMeasurement,64,WTF::CrashOnOverflow,16> & wordMeasurements) Line 110 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutRunsAndFloatsInRange(WebCore::LineLayoutState & layoutState, WebCore::BidiResolver<WebCore::InlineIterator,WebCore::BidiRun> & resolver, const WebCore::InlineIterator & cleanLineStart, const WebCore::BidiStatus & cleanLineBidiStatus, unsigned int consecutiveHyphenatedLines) Line 1260 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutRunsAndFloats(WebCore::LineLayoutState & layoutState, bool hasInlineChild) Line 1214 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutLineBoxes(bool relayoutChildren, WebCore::LayoutUnit & repaintLogicalTop, WebCore::LayoutUnit & repaintLogicalBottom) Line 1624 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlock(bool relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 484 C++
> WebKit.dll!WebCore::RenderBlock::layout() Line 930 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 712 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 632 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlock(bool relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 485 C++
> WebKit.dll!WebCore::RenderBlock::layout() Line 930 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 712 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 632 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlock(bool relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 485 C++
> WebKit.dll!WebCore::RenderBlock::layout() Line 930 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 712 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 632 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlock(bool relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 485 C++
> WebKit.dll!WebCore::RenderBlock::layout() Line 930 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 712 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 632 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlock(bool relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 485 C++
> WebKit.dll!WebCore::RenderBlock::layout() Line 930 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 712 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 632 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlock(bool relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 485 C++
> WebKit.dll!WebCore::RenderBlock::layout() Line 930 C++
> WebKit.dll!WebCore::RenderBlockFlow::insertFloatingObject(WebCore::RenderBox & floatBox) Line 2247 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 627 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlock(bool relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 485 C++
> WebKit.dll!WebCore::RenderBlock::layout() Line 930 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 712 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 632 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlock(bool relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 485 C++
> WebKit.dll!WebCore::RenderBlock::layout() Line 930 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 712 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 632 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlock(bool relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 485 C++
> WebKit.dll!WebCore::RenderBlock::layout() Line 930 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 712 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 632 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlock(bool relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 485 C++
> WebKit.dll!WebCore::RenderBlock::layout() Line 930 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 712 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 632 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlock(bool relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 485 C++
> WebKit.dll!WebCore::RenderBlock::layout() Line 930 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 712 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 632 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlock(bool relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 485 C++
> WebKit.dll!WebCore::RenderBlock::layout() Line 930 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 712 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 632 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlock(bool relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 485 C++
> WebKit.dll!WebCore::RenderBlock::layout() Line 930 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 712 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 632 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlock(bool relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 485 C++
> WebKit.dll!WebCore::RenderBlock::layout() Line 930 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 712 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 632 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlock(bool relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 485 C++
> WebKit.dll!WebCore::RenderBlock::layout() Line 930 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 712 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 632 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlock(bool relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 485 C++
> WebKit.dll!WebCore::RenderBlock::layout() Line 930 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 712 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 632 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlock(bool relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 485 C++
> WebKit.dll!WebCore::RenderBlock::layout() Line 930 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox & child, WebCore::RenderBlockFlow::MarginInfo & marginInfo, WebCore::LayoutUnit & previousFloatLogicalBottom, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 712 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, WebCore::LayoutUnit & maxFloatLogicalBottom) Line 632 C++
> WebKit.dll!WebCore::RenderBlockFlow::layoutBlock(bool relayoutChildren, WebCore::LayoutUnit pageLogicalHeight) Line 485 C++
> WebKit.dll!WebCore::RenderBlock::layout() Line 930 C++
> WebKit.dll!WebCore::RenderView::layoutContent(const WebCore::LayoutState & state) Line 256 C++
> WebKit.dll!WebCore::RenderView::layout() Line 382 C++
> WebKit.dll!WebCore::FrameView::layout(bool allowSubtree) Line 1429 C++
> WebKit.dll!WebCore::Document::updateLayout() Line 1889 C++
> WebKit.dll!WebCore::Document::updateLayoutIgnorePendingStylesheets(WebCore::Document::RunPostLayoutTasks runPostLayoutTasks) Line 1922 C++
> WebKit.dll!WebCore::Element::getBoundingClientRect() Line 1071 C++
> WebKit.dll!WebCore::jsElementPrototypeFunctionGetBoundingClientRect(JSC::ExecState * exec) Line 5165 C++
> [External Code]
> JavaScriptCore.dll!llint_entry() Line 8217 Unknown
> [External Code]
> JavaScriptCore.dll!llint_entry() Line 8217 Unknown
>
>
> From: Vienneau, Christopher
> Sent: Friday, November 20, 2015 5:20 PM
> To: 'WebKit Development' <webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>>
> Subject: RE: Memory leak tracking in WebKit
>
> 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::RefPtr<WTF::UniquedStringImpl>,WTF::KeyValuePair<WTF::RefPtr<WTF::UniquedStringImpl>,JSC::VariableEnvironmentEntry>,WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WTF::RefPtr<WTF::UniquedStringImpl>,JSC::VariableEnvironmentEntry> >,JSC::IdentifierRepHash,WTF::HashMap<WTF::RefPtr<WTF::UniquedStringImpl>,JSC::VariableEnvironmentEntry,JSC::IdentifierRepHash,WTF::HashTraits<WTF::RefPtr<WTF::UniquedStringImpl> >,JSC::VariableEnvironmentEntryHashTraits>::KeyValuePairTraits,WTF::HashTraits<WTF::RefPtr<WTF::UniquedStringImpl> > >::HashTable<WTF::RefPtr<WTF::UniquedStringImpl>,WTF::KeyValuePair<WTF::RefPtr<WTF::UniquedStringImpl>,JSC::VariableEnvironmentEntry>,WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WTF::RefPtr<WTF::UniquedStringImpl>,JSC::VariableEnvironmentEntry> >,JSC::IdentifierRepHash,WTF::HashMap<WTF::RefPtr<WTF::UniquedStringImpl>,JSC::VariableEnvironmentEntry,JSC::IdentifierRepHash,WTF::HashTraits<WTF::RefPtr<WTF::UniquedStringImpl> >,JSC::VariableEnvironmentEntryHashTraits>::KeyValuePairTraits,WTF::HashTraits<WTF::RefPtr<WTF::UniquedStringImpl> > > + 153
> \javascriptcore\local\javascriptcore\parser\parser.cpp(1347): JSC::Parser<JSC::Lexer<unsigned char> >::parseTryStatement<JSC::ASTBuilder> + 1984
> \javascriptcore\local\javascriptcore\parser\parser.cpp(1480): JSC::Parser<JSC::Lexer<unsigned char> >::parseStatement<JSC::ASTBuilder> + 671
> \javascriptcore\local\javascriptcore\parser\parser.cpp(497): JSC::Parser<JSC::Lexer<unsigned char> >::parseStatementListItem<JSC::ASTBuilder> + 100
> \javascriptcore\local\javascriptcore\parser\parser.cpp(379): JSC::Parser<JSC::Lexer<unsigned char> >::parseSourceElements<JSC::ASTBuilder> + 745
> \javascriptcore\local\javascriptcore\parser\parser.cpp(1406): JSC::Parser<JSC::Lexer<unsigned char> >::parseBlockStatement<JSC::ASTBuilder> + 741
> \javascriptcore\local\javascriptcore\parser\parser.cpp(1433): JSC::Parser<JSC::Lexer<unsigned char> >::parseStatement<JSC::ASTBuilder> + 179
> \javascriptcore\local\javascriptcore\parser\parser.cpp(497): JSC::Parser<JSC::Lexer<unsigned char> >::parseStatementListItem<JSC::ASTBuilder> + 100
> \javascriptcore\local\javascriptcore\parser\parser.cpp(379): JSC::Parser<JSC::Lexer<unsigned char> >::parseSourceElements<JSC::ASTBuilder> + 171
> \javascriptcore\local\javascriptcore\parser\parser.cpp(277): JSC::Parser<JSC::Lexer<unsigned char> >::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 <webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>>
> 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 <http://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
> <WebKitMessageLoop.cpp><Common.cpp>_______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20151201/f6f3ae78/attachment-0001.html>
More information about the webkit-dev
mailing list