[webkit-dev] Memory leak tracking in WebKit
Vienneau, Christopher
cvienneau at ea.com
Thu Dec 10 00:13:15 PST 2015
Hi Myles,
(condensed version, since it was too long for the mail list)
I’ve made progress on identifying what is causing the leak, I haven’t yet identified what is special about this case, maybe you can help me there. Long story short, the document isn’t being destroyed, at the time I would expect it to be ready for destruction, it still has a m_referencingNodeCount of 2.
I’m now able to create a much simpler test case to reproduce the problem, this simple web page will create the leak:
<!DOCTYPE html>
<html>
<title>SVG polyline test</title>
<head>SVG polyline test</head>
<style>
#pic {
}
</style>
<body>
<div>
<svg version="1.1" id="angle_overlay" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="1360px" height="119.3px" preserveAspectRatio="xMaxYMax meet" viewBox="0 0 1360 119.3"><polyline class="st0" fill="#123456" points="1360,119.3 1360,0 0,119.3"></polyline></svg>
<img id="pic" src="test.jpg">
</div>
</body>
</html>
I have also been able to reproduce the issue in the WinLauncher sample app. Using the basic soaking features that I put into WinLauncher for this investigation (mentioned earlier in the thread) I was able to see the same leak happen there, both in code/logging and in memory growth. Its far easier to track the leak when caching is off so in WebView.cpp I modified the code to disable pagecache and memory cache:
auto& memoryCache = MemoryCache::singleton();
//memoryCache.setCapacities(cacheMinDeadCapacity, cacheMaxDeadCapacity, cacheTotalCapacity);
//memoryCache.setDeadDecodedDataDeletionInterval(deadDecodedDataDeletionInterval);
memoryCache.setDisabled(true);
PageCache::singleton().setMaxSize(0);
I also added some logging in Document’s constructor and destructor and at the point where I initiate loading each page. The output looks like so:
load svg.html
Document Created
Document Destroyed
load image.html
Document Created
load svg.html
Document Created
Document Destroyed
load image.html
Document Created
(ect)
Notice how when we transition from the svg.html to the image.html we don’t cause a destruction of the document we were currently on. I’ve attached the web pages that I used for this test.
Tomorrow will be my last day in the office until January, I’ll spend the day trying to track down what is happening causing the svg tag to leak. If you have any advice to provide it’ll be much appreciated, it would feel good to get this one all tied up before I’m out of office.
Thanks
Chris
From: mmaxfield at apple.com<mailto:mmaxfield at apple.com> [mailto:mmaxfield at apple.com]
Sent: Friday, December 04, 2015 11:51 PM
To: Vienneau, Christopher <cvienneau at ea.com<mailto:cvienneau at ea.com>>
Subject: Re: [webkit-dev] Memory leak tracking in WebKit
I don't really have any other hints; your destroy.txt looks like the Document is being destroyed from JavaScript (during a garbage collection) and is taking the style objects with it. Either the Document isn't getting destroyed, or it isn't holding the last reference to the style objects. Because you have a working case and a nonworking case, it sounds like you should be able to figure out what is changing.
You could also try disabling JavaScript entirely and repeating the test, to see if JavaScript has anything to do with the problem.
We are very interested to see what is ending up causing the leak!
--Myles
On Dec 4, 2015, at 5:22 PM, Vienneau, Christopher <cvienneau at ea.com<mailto:cvienneau at ea.com>> wrote:
Hi Myles,
I did some more investigation on this, I’ve been comparing an older version of our program based on 157437 with stable memory VS our latest based on 188436 which is showing the memory leak. In both version the callstack for allocating the leaking font face looks similar to the callstack from alloc.txt.
However in the new version the destructor is never called, in the old version destruction would come via the callstack from detroy.txt.
I’ve also compared to WinCairo at 188436 it allocates the font face and never destroys it too, however in our application we allocate on every test iteration whereas the WinCairo sample only allocates on the first pass through (could be caching working properly there). I’ve been attempting to compare the 15x VS 18x execution paths to see what is missing preventing it from deallocation but I haven’t come up with anything actionable yet. If this information gives you some other hints I might follow, I’d be interested to hear.
Thanks
Chris Vienneau
From: Vienneau, Christopher
Sent: Wednesday, December 02, 2015 2:07 PM
To: 'mmaxfield at apple.com<mailto:mmaxfield at apple.com>' <mmaxfield at apple.com<mailto:mmaxfield at apple.com>>
Cc: WebKit Development <webkit-dev at lists.webkit.org<mailto:webkit-dev at lists.webkit.org>>
Subject: RE: [webkit-dev] Memory leak tracking in WebKit
>> Your first 4 stack traces are items which are put into our memory cache, and then held on to for subsequent page loads.
I expect the items to be removed from the cache at step 4 of the repro steps though, just before I copy the memory logs I clear the cache. I also wouldn’t expect it to grow forever.
>> We don't destroy Documents when you navigate away from them; instead, they are placed into the page cache
We have the page cache disabled in our program by setting WebCore::PageCache::singleton().setMaxSize(0); I don’t find that anything has found its way into the page cache when investigating.
>> a good first step would probably be to investigate the classes at WebCore/history/PageCache.h and WebCore/loader/cache/MemoryCache.h.
I wanted to rule out caching as a problem, as mentioned above we already weren’t using the page cache but I decided to disable the memory cache too.
WebCore::PageCache::singleton().setMaxSize(0);
WebCore::MemoryCache::singleton().setDisabled(true);
To my surprise instead of the leak going away it has become worse (leaking 13MB every test iteration), I did a new set of memory log captures to see what was going on. I found a new item in the #1 position:
index
Callstack hash
alignment
requested
actual
count
total
Delta
last label
3554490
EAWebKit::34a764
0
4428160
4431840
3
13295520
3
http://answers.ea.com/t5/Answer-HQ-English/ct-p/AHQ-English
dev\webkit\ea\api\eawebkit\source\eawebkitallocator.cpp(412): WTF::tryFastMalloc + 28
dev\eawebkitsupportpackages\wtf\local\wtf\vector.h(280): WTF::VectorBufferBase<unsigned int>::tryAllocateBuffer + 52
dev\eawebkitsupportpackages\wtf\local\wtf\vector.h(1113): WTF::Vector<unsigned int,0,WTF::CrashOnOverflow,16>::tryReserveCapacity + 50
dev\webcore\platform\image-decoders\imagedecoder.cpp(223): WebCore::ImageFrame::setSize + 59
dev\webcore\platform\image-decoders\jpeg\jpegimagedecoder.cpp(736): WebCore::JPEGImageDecoder::outputScanlines + 173
dev\webcore\platform\image-decoders\jpeg\jpegimagedecoder.cpp(443): WebCore::JPEGImageReader::decode + 582
dev\webcore\platform\image-decoders\jpeg\jpegimagedecoder.cpp(803): WebCore::JPEGImageDecoder::decode + 215
dev\webcore\platform\image-decoders\jpeg\jpegimagedecoder.cpp(641): WebCore::JPEGImageDecoder::frameBufferAtIndex + 93
dev\webcore\platform\graphics\imagesource.cpp(207): WebCore::ImageSource::frameIsCompleteAtIndex + 25
dev\webcore\platform\graphics\bitmapimage.cpp(206): WebCore::BitmapImage::cacheFrame + 333
The other css related callstacks are still present too, such as:
c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\eawebkitsupportpackages\wtf\local\wtf\vector.h(1099): WTF::Vector<unsigned char,0,WTF::CrashOnOverflow,16>::reserveCapacity + 57
c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\eawebkitsupportpackages\wtf\local\wtf\vector.h(1011): WTF::Vector<unsigned char,0,WTF::CrashOnOverflow,16>::resize + 95
c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\platform\sharedbuffer.cpp(327): WebCore::SharedBuffer::buffer + 46
c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\platform\sharedbuffer.cpp(141): WebCore::SharedBuffer::data + 18
c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\loader\cache\cachedcssstylesheet.cpp(100): WebCore::CachedCSSStyleSheet::finishLoading + 144
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\platform\network\ea\resourcehandlemanagerea.cpp(788): WebCore::ResourceHandleManager::ProcessJobState + 239
c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\platform\network\ea\resourcehandlemanagerea.cpp(697): WebCore::ResourceHandleManager::ProcessJobs + 113
and
c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\eawebkitsupportpackages\wtf\local\wtf\text\stringimpl.cpp(247): WTF::StringImpl::createInternal<char16_t> + 69
c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\eawebkitsupportpackages\wtf\local\wtf\text\stringimpl.cpp(254): WTF::StringImpl::create + 14
c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\eawebkitsupportpackages\wtf\local\wtf\text\wtfstring.cpp(47): WTF::String::String + 31
c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\css\cssparservalues.h(98): WebCore::CSSParserString::operator WTF::String + 67
c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\css\cssparser.cpp(6924): WebCore::CSSParser::parseFontFaceSrcURI + 94
c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\css\cssparser.cpp(6988): WebCore::CSSParser::parseFontFaceSrc + 128
c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkit\dev\webcore\css\cssparser.cpp(2376): WebCore::CSSParser::parseValue + 1442
c:\eaos\eaos\eawebkit\sb\pullfromtrunk\eawebkitdemoutfwin\dev\build\win64\eawebkit\dev\cssgrammar.y(1294): cssyyparse + 1185
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
I’m investigating the new top callstack now, it seems like its hanging onto the whole frame buffer
From: mmaxfield at apple.com<mailto:mmaxfield at apple.com> [mailto:mmaxfield at apple.com]
Sent: Tuesday, December 01, 2015 4:04 PM
To: Vienneau, Christopher <cvienneau at ea.com<mailto:cvienneau at ea.com>>
Cc: WebKit Development <webkit-dev at lists.webkit.org<mailto:webkit-dev at lists.webkit.org>>
Subject: Re: [webkit-dev] Memory leak tracking in WebKit
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<mailto: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 and 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 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
2685982
EAWebKit::9a6160de
0
1018137
1018160
2
2036320
2
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
361390
EAWebKit::9a6160de
0
742719
742736
1
742736
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
1565700
EAWebKit::9a6160de
0
370617
370640
1
370640
2
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
1858772
EAWebKit::fec447
0
321182
323552
2
647104
2
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
2843994
EAWebKit::86d391
0
284812
286688
1
286688
1
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
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
2685982
EAWebKit::9a6160de
0
1018137
1018160
2
2036320
2
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
361390
EAWebKit::9a6160de
0
742719
742736
1
742736
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
1565700
EAWebKit::9a6160de
0
370617
370640
1
370640
2
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
\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
\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
\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
\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
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
\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
2802991
EAWebKit::7ff003ec20e
0
18
32
5362
171584
5863
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
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> [mailto:mmaxfield at apple.com]
Sent: Monday, November 30, 2015 5:43 PM
To: Vienneau, Christopher <cvienneau at ea.com<mailto:cvienneau at ea.com>>
Cc: WebKit Development <webkit-dev at lists.webkit.org<mailto: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
<alloc.txt><destroy.txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20151210/05a48e06/attachment-0003.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20151210/05a48e06/attachment-0004.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20151210/05a48e06/attachment-0005.html>
More information about the webkit-dev
mailing list