[webkit-dev] Questions regarding memory debugging

[Greg Simon]

This would be a really great topic for the webkit meeting in April. At Palm we spend a significant amount of development time dealing with memory "growth" (not so much leaks).  Google perf tools has worked very well for us on desktop as it gives the complete call stack showing how the allocation was made. On device, we use a lot of live object instance monitoring. Anyway it would be great to share some tips and tricks with other folks.

Greg



On 3/10/10 9:51 AM, "Darin Adler" <darin at apple.com> wrote:

On Mar 9, 2010, at 8:56 PM, Holger Freyther wrote:

Now SharedBuffer is refcounted and can only "leak" if someone is holding a reference to it and this is where stuff gets tricky. Besides manually searching the tree and adding printf's all over has anyone found a better way of doing this?

One of the best techniques we have found is to detect the leak when it is introduced. A technique we use is to add monitoring to classes for which there should be no instances at process exit, and log a complaint if objects are still around. Then the leak message can be spotted on the check-in that introduces it.

I've done a lot of manual work with gdb to track down reference count mismatches, reference cycles, and such.

At the OpenBSC GSM Project we are using this C library talloc. With talloc every allocation is happening inside a (hierachical) context and at runtime we can send a SIGUSR1 one to the application and the memstatistics are dumped on the console. I have attached an example output so you guys can see it.

I wonder if such a thing would make sense in a debug build as well? I wonder if we could change the common Class::create methods to take a context, or at least an area (Render, Network, Platform) and if these get created in a special debug build we add these objects to a list for these contexts and we
can dump the information... e.g. # of allocated bytes, ref count and such? Does this sound crazy or too invasive?

Changes that involve modifying every allocation are challenging and could take a lot of work to do. There are many, many separate calls to new.

But more importantly, how would this help with the SharedBuffer problem? It seems like a separate topic.

We have memory tools on Mac OS X that group allocations by the call stack when an object is allocated, and we have come up with scripts that help us put allocations into "areas" as you suggest, without adding code to WebKit.

But in cases like the SharedBuffer one, there is no mystery about who allocated the memory. The mystery is typically who is holding on to a reference to it.

    -- Darin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100310/4d667913/attachment.html>