[webkit-dev] freeing static variables

tonikitoo (Antonio Gomes) tonikitoo at gmail.com
Thu Jul 30 07:06:35 PDT 2009


Zoltan, I think it would be a great add from a embedder-dev point of view.

Particularly, such leaks have been faced here in a soon past, when we
were loading a webkit browser as a plugin, and not as an application
by itself. So, we the webkit plugin was unloaded, it used to left
behind lots of leaks affecting the (main)  loader application, and as
we you might imagine many of this leaks were from global vars
(including in dependency libs , e.g. fontconfig =/)

On Wed, Jul 29, 2009 at 4:05 AM, Zoltan Herczeg<zherczeg at inf.u-szeged.hu> wrote:
> Hi all,
>
> Valgrind reports a lot of memory leaks when QtLauncher quits, because many
> static local variables are not freed. I did a little research and realized
> there is no consistent way to define static variables in webkit:
>
> WebCore/css/CSSSelector.cpp: CSSSelector::extractPseudoType()
>   using a DEFINE_STATIC_LOCAL() macro
>
> WebCore/bindings/js/JSDOMWindowBase.cpp:
> JSDOMWindowBase::commonJSGlobalData()
>   static JSGlobalData* globalData;
>
> WebCore/platform/qt/CursorQt.cpp:
>   Cursors* Cursors::s_self = 0; (no static keyword)
>
> I belive it would be a good thing to define a template for static
> variables, which can (optionally) free static variables (enabled in debug
> mode, but sometimes it would be good to enable it in release mode as well)
>
> And I am wondering whether it would be worth to free (some) static
> variables if they are used in a given time period. This may help to reduce
> the memory consumption in the long run. This would be an optional feature,
> an extra flag (or timeout value) for the template, which can be enabled or
> disabled at compile time. If disabled, the value of this flag is not used
> at all.
>
> Regards
> Zoltan
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



-- 
--Antonio Gomes


More information about the webkit-dev mailing list