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
Hi, any thoughts on this? I hope my qestion was clear :) I would like to pack the static declarations into wrapper classes, so we can add platform and/or compilation mode (debug/release) dependent functionality to all static variables (i.e: freeing them on exit). Zoltan
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
On Thursday 30 July 2009 02:55:18 am Zoltan Herczeg wrote:
Hi,
any thoughts on this? I hope my qestion was clear :) I would like to pack the static declarations into wrapper classes, so we can add platform and/or compilation mode (debug/release) dependent functionality to all static variables (i.e: freeing them on exit).
Zoltan
I've tried this before and it didn't work out so well. The order in which you free them becomes very important and error prone. And, of course, whatever solution you make has to be optional and easy to maintain as the default policy in WebKit is to not care - by design - about cleaning up after static globals on exit as that is left to the OS. Another strategy for the embedded case where you want to free everything on exit is to create a custom memory handler that will do this for you. Cheers, Adam
Hi Adam, thank you for your suggestions. I have something similar in my mind. I have opened a bugzilla entry and submited an early patch draft about my concept: https://bugs.webkit.org/show_bug.cgi?id=27980 The patch frees memory objects in a reversed creation order, and seemed working well with QtLauncher (although only a subset of static variables are freed right now). Do you know about special cases when this approach is not enough? Actually it is hard to find real memory leaks in the output of valgrind because many of them are related to static variables. I hope this feature will help to the leak hunters in the future. Cheers, Zoltan
On Thursday 30 July 2009 02:55:18 am Zoltan Herczeg wrote:
Hi,
any thoughts on this? I hope my qestion was clear :) I would like to pack the static declarations into wrapper classes, so we can add platform and/or compilation mode (debug/release) dependent functionality to all static variables (i.e: freeing them on exit).
Zoltan
I've tried this before and it didn't work out so well. The order in which you free them becomes very important and error prone.
And, of course, whatever solution you make has to be optional and easy to maintain as the default policy in WebKit is to not care - by design - about cleaning up after static globals on exit as that is left to the OS.
Another strategy for the embedded case where you want to free everything on exit is to create a custom memory handler that will do this for you.
Cheers, Adam
How do the scroll areas that encompass text areas fit into the render tree? I need to turn that scroll area into an accessible object, but when I look at the render tree i don't see anything that would indicate there is a renderer associated with the scroll area. thanx
On Aug 4, 2009, at 2:57 PM, Chris Fleizach wrote:
How do the scroll areas that encompass text areas fit into the render tree?
I need to turn that scroll area into an accessible object, but when I look at the render tree i don't see anything that would indicate there is a renderer associated with the scroll area.
The class that handles this is RenderTextControlMultiLine, which is derived from RenderTextControl, then from RenderBlock. Like any other block, if the CSS overflow is set appropriately there can be scroll bars. You should see a RenderTextControlMultiLine in the render tree, with functions like scrollsOverflowX() and scrollsOverflowY() indicating the presence of scroll bars. -- Darin
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@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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-- --Antonio Gomes
participants (5)
-
Adam Treat
-
Chris Fleizach
-
Darin Adler
-
tonikitoo (Antonio Gomes)
-
Zoltan Herczeg