En 02/11/10 09:23, Sergio Villar Senin escribiu: > En 02/11/10 08:33, Toni Koski escribiu: >> No effect with g_free(). Still leaking. >> Yes, I have tested with uzbl also. With "www.hs.fi" I can see that the >> used memory increases when the page is reloaded again and again :-( > > Maybe the problem is related to the new HTTP cache we added recently. > Even if you do not use it, you'll be using the new stream based loading > code needed by cache. I can help with that, just ping me (sergio) on IRC.
After investigating a little bit it seems that it's not cache's issue. BTW running your example with valgrind gives me the following outcome after 5 reloads: ==23248== LEAK SUMMARY: ==23248== definitely lost: 8,804 bytes in 36 blocks ==23248== indirectly lost: 21,540 bytes in 1,051 blocks ==23248== possibly lost: 1,206,326 bytes in 9,118 blocks ==23248== still reachable: 758,669 bytes in 4,566 blocks ==23248== suppressed: 14,516 bytes in 270 blocks This includes all the libraries used by webkitgtk. There is only 8k of definitely lost memory. After 20 reloads I got this: ==23488== definitely lost: 12,817 bytes in 86 blocks ==23488== indirectly lost: 28,500 bytes in 1,387 blocks ==23488== possibly lost: 1,404,947 bytes in 9,443 blocks ==23488== still reachable: 1,051,558 bytes in 4,774 blocks ==23488== suppressed: 15,988 bytes in 297 blocks So 12k of definitely lost memory after 20 reloads. Most of the possibly lost stuff is related to font handling as far as I saw. What is the "huge" leak you identified? What tools are you using? Br _______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
