GNOME Bugzilla – Bug 744401
Many WebKitDom objects leaked for every message viewed
Last modified: 2018-10-26 06:30:32 UTC
Evolution has frequently been reaching 10GiB of memory usage, and has needed to be killed. Running with latest gtk and GOBJECT_DEBUG=instance-count, I can see that every time I move from one message preview to another (and back again by pressing up, down, up, down cursors in the folder index), I gain another 55 WebKitDomNodeList objects and another 41 WebKitDOMCSSRule objects. These are simple plain text emails — and short ones, not the type that causes WebKit to go off into the weeds for hours at a time until gnome-shell reports that Evolution isn't responding and it gets killed for *that* reason instead (bug 704271 unfixed since July 2013 and still happening).
Possibly related webkit bug: https://bugs.webkit.org/show_bug.cgi?id=118788
There had been done some fixes in the upstream bug mentioned at comment #1, thus let's close this as such.
I'm sorry, I'm reopening this. KaL told me that it's not as I understood it. The function annotations are not always correct in WebKit, while they claim transfer-none, they are actually transfer-full. Luckily, their DOMObjectCache is smart enough that it stops tracking freed objects on its own. There are objects which can be freed on the webkit's frame dispose, but we are only partially lucky with it, because evolution reuses the same web view, which had the same frame. Evolution uses iframe-s, that's why only partly. The frame free still needs a change on the webkit side.
The WebKitDOMCSSRuleList leaks are fixed with commit[0] in the master branch for Evolution 3.15.91+. [0] - https://git.gnome.org/browse/evolution/commit/?id=67bdc6787835ea713de7583c8ed8a3cf1c8ddb5c
Another follow-up commit[0] with more fixes for Evolution 3.15.91+. [0] - https://git.gnome.org/browse/evolution/commit/?id=88dd1d83c9a2e95c18dc0a26602f9a738c839b99
Created attachment 297636 [details] debug wk patch Just for an easier debugging, this adds two new functions: webkit_web_view_dom_object_cache_set_pointer_callabacks() webkit_web_view_dom_object_cache_dump_pointers() which helps with identifying left pointers in the DOMObjectCache.
Created attachment 297638 [details] debug evo patch This uses the two debug functions in evolution. If evolution-data-server is configured with --enable-backtraces and the elf-utils or some such was available during the configure time, then it can also print backtraces where the objects were allocated. It's quite slow, thus the patch has the call to webkit_web_view_dom_object_cache_set_pointer_callabacks() commented out.
The above patches helped me to identify few more leaks, which I addressed at commit 9f6da53 (3.15.91+).
Running 3.15.92 (in Fedora 22) I still see the count of WebKitDOMRange objects constantly increasing as I type into a message composer.
(In reply to David Woodhouse from comment #9) > Running 3.15.92 (in Fedora 22) I still see the count of WebKitDOMRange > objects constantly increasing as I type into a message composer. That is expected. The view is supposed to clean itself when the composer is closed.
I'm closing this. With the port to WebKit2 the WebKitDOMRange objects are freed as soon as they are not needed. They are also created on the WebKitWebProcess side.