> 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-boun...@lists.webkit.org [mailto:webkit-gtk-boun...@lists.webkit.org] On Behalf Of Sergio Villar Senin Sent: 13 June 2013 17:03 To: webkit-gtk@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@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-gtk _______________________________________________ webkit-gtk mailing list webkit-gtk@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-gtk
