[webkit-dev] Leak reports during shutdown

Kevin Ollivier kevino at theolliviers.com
Tue Sep 29 14:14:49 PDT 2009

Hi Zoltan,

On Sep 29, 2009, at 12:39 PM, Zoltan Herczeg wrote:

> Hi Kevin,
> WebKit approach is NOT to free memory before quit to make the quit  
> process
> as fast as possible. The memory manager should free the unfreed  
> objects.
> However, this approach makes really hard to find the "real" leaks  
> (which
> are unreferenced objects).
> In my experince the unfreed (non-leak) objects come from several  
> sources:
>  - JavaScriptCore garbage collector is not called before quit
>  - Caches are not cleared before quit
> The previous two are performed by QtLauncher in debug mode. See
> WebKit/qt/QtLauncher/main.cpp launcherMain()
>  - In case of workers, the gc() does not called for each worker  
> threads
> when the application quits. The JavaScript threads are simply aborted.
>  - Global objects are not freed at all. There was an attempt to free  
> them
> (see https://bugs.webkit.org/show_bug.cgi?id=27980 ) but seems not  
> worth
> to continue that work, although it helped to find leaks such as this:
> https://bugs.webkit.org/show_bug.cgi?id=29295
> The remaining unfreed objects are possible leaks. Many of them are
> probably port specific (not all port maintainers have resources to  
> keep
> leak hunters).

Thanks for the detailed response, this makes things very clear! :-) (&  
thanks to Darin for his info about leak checkers) I guess I didn't  
really expect things to work this way in debug mode as it seems to me  
RefCountedLeakChecker pretty much needs those resources to be freed in  
order to provide useful leak reports. In any case, I've been thinking  
about adding some APIs to manage the cache to wxWebKit and now I've  
got even more of an incentive to code something up. :-)



> Zoltan
>> Hi all,
>> For a while, ports like wx and Win/Cairo have been seeing various
>> leaks reported on shutdown, but at least on Mac I've been unable to
>> see these leaks using memory leak checkers like the one in
>> Instruments, so I decided to poke into the code a bit more and try to
>> understand what's going on a bit better.
>> What I found was that the reported object leaks were pretty much all
>> related to objects that JSC has references to. Changing
>> ~ScriptController to do a garbageCollectNow() instead of
>> garbageCollectSoon(), for example, drastically reduced the number of
>> reported leaks, cleaning up all the CachedResource leaks and almost
>> all the WebCoreNode leaks. The remaining leaks were almost all
>> JSC::Structure objects. I've been digging through the code to try and
>> find the place where these JSC objects are finally deleted, but I
>> haven't found anyplace obvious in the code, neither in common code  
>> nor
>> in the ports' code.
>> My question is, is there somewhere these objects are being deleted on
>> final shutdown that apparently happens after the leaks are reported,
>> or does WebKit have assumptions such as that all still running timers
>> must fire before final shutdown that ports such as ours are not
>> honoring? (e.g. in my tests garbageCollectSoon() does not end up
>> firing the callback because the app shuts down too fast.)
>> Thanks,
>> Kevin
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

More information about the webkit-dev mailing list