[webkit-dev] Memory leak tracking in WebKit

Vienneau, Christopher cvienneau at ea.com
Fri Nov 20 17:20:23 PST 2015


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>
Subject: Memory leak tracking in WebKit

Hi,

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

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

Thanks for any suggestions

Chris Vienneau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20151121/a4596042/attachment.html>


More information about the webkit-dev mailing list