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