[webkit-gtk] Memory leaks creating and removing webviews

[Brian Holt]

> I am not saying that there are no leaks, but it's better to use tools like
valgrind as it can properly point to the sources of potential memory leaks.

I've just finished running all the LayoutTests (30K+) with the
DumpRenderTree under valgrind
(https://bugs.webkit.org/show_bug.cgi?id=116317) and the good news is that
there are only a few leaks in WK Gtk, mostly one-off leaks in external
libraries like enchant, fontconfig, GL etc.

Also, running a page making XMLHttpRequests on the DRT under valgrind shows
that there are no "leaks" in the sense that memory is no longer available.
What is far more likely is that the references are being held in some
structure (HashTable?) and upon exit are properly freed.  

Regards
Brian
 
-----Original Message-----
From: webkit-gtk-bounces at lists.webkit.org
[mailto:webkit-gtk-bounces at lists.webkit.org] On Behalf Of Sergio Villar
Senin
Sent: 13 June 2013 17:03
To: webkit-gtk at lists.webkit.org
Subject: Re: [webkit-gtk] Memory leaks creating and removing webviews

En 12/06/13 20:49, Josh Rickmar escribiu:
> This issue may have already been beaten to death, but I am seeing 
> pretty bad memory leaks when creating, showing and, and then deleting 
> WebKitWebView widgets.  I've written and attached a very small test 
> browser that will open tabs to Google's homepage, with a button on 
> each tab to remove the tab and free everything in that notebook's 
> page's container.  From what I can observe with top, I lose roughly 3 
> MB per each tab open and close.

The thing is that if you're only using top to look for leaks then I don't
think you're using the right approach. Note that a call to free() does not
really return the memory to the OS. The standard libc allocator will not
actually free memory pages when free() is called, since that's a costly
operation. Instead, the library tracks allocations and reuses pages for the
next allocations.

The consequence is that the RSS value reported by top will never decrease
(unless the OS detects a memory shortfall and claims for some memory pages).

This will change with the multi-webprocess architecture, as each tab
(browsing context to be more precise) will use a different webprocess, so
closing a tab will mean finalizing a process, something that immediately
returns the memory to the OS.

I am not saying that there are no leaks, but it's better to use tools like
valgrind as it can properly point to the sources of potential memory leaks.

BR
_______________________________________________
webkit-gtk mailing list
webkit-gtk at lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk