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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
