PC에서 Visual Studio 디버그 모드로 웹킷을 실행시켰다 종료시키면 기절할 정도로 많은 메모리 leak이 보고된다.
처음엔 명성 높은 웹킷 소스에서 그토록 많은 leak이 쏟아진다는 것이 믿어지지 않았다. 처음 프로그래밍을 배울 때 메모리 leak은 하나도 남김 없이 제거해야 할 절대 악으로 배웠다. 그래서 메모리 leak에 대해서는 강박관념에 가까운 혐오를 갖고 있다. 그런데 결론을 말하자면 WebKit 소스가 종료시 내는 leak은 의도적인 것이라고 한다. 종료 시점에 사용하던 메모리를 해지하는 절차를 생략함으로써 (해당 절차를 OS에게 맡김으로써) 처리 속도를 높이는 것이 설계 취지란다. 딱히 반박할 수도 없고... 경우에 따라서는 합리적인 판단일 수도 있겠다 하고 수긍하고 있다. 관련된 뉴스 그룹 기사는 다음과 같다.
http://www.nabble.com/freeing-static-variables-to24714380.html
뉴스 그룹 기사를 요약하면 다음과 같다.
static global 변수의 leak은 의도적이다 (by "Adam Treat-2")
* 웹킷은 static global 변수의 해지(clean up)에 관여하지 않는다. 해당 작업은 OS에게 맡긴다.
의도적인 leak에 대한 태클 (by "Zoltan" and "Antonio Gomes")
* 보고되는 leak이 너무 많아, 실제 주의해야 할 개발자의 실수에 의한 leak을 알아내기 어렵다.
* WebKit을 어플리케이션 형태가 아닌 다른 어플리케이션의 플러그인 형태로 사용할 경우, WebKit 플러그인을 내릴 때 leak이 발생하면 문제가 된다.
참고를 위해 뉴스 기사 원문을 아래와 같이 첨부한다.
_______________________________________________
freeing static variables
by Zoltan Herczeg Jul 29, 2009; 05:05pm
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
_______________________________________________
Re: freeing static variables
by Zoltan Herczeg Jul 30, 2009; 03:55pm
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
_______________________________________________
Re: freeing static variables
by tonikitoo (Antonio Gomes) Jul 30, 2009; 11:06pm
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 =/)
--Antonio Gomes
_______________________________________________
Re: freeing static variables
by Adam Treat-2 Jul 30, 2009; 11:26pm
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
_______________________________________________
Re: freeing static variables
by Zoltan Herczeg Aug 05, 2009; 12:10am
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
(끝)
