[Webkit-unassigned] [Bug 118788] [GTK] WebKitDOM objects leaking

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=118788

--- Comment #7 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #6)
> (In reply to comment #5)
> > Created attachment 246517 [details]
> > wk-leaks.c
> > 
> > Test application (first line shows how to compile & run it), which makes it
> > easier to reproduce the leaks. Similar code (update_styles()) is used in
> > Evolution and called to quite few times on various occasions.
> > 
> > The thing is that objects like WebKitDOMCSSRuleList (returned from
> > webkit_dom_css_style_sheet_get_css_rules()) and WebKitDOMCSSRule (returned
> > from webkit_dom_css_rule_list_item()) are not freed on frame reload, but a
> > new objects are returned anyway.
> > 
> > The reason is that DOMObjectCache::clearByFrame() is called with a valid
> > frame, but these objkects (and many other DOM objects) are stored in the
> > cache with NULL data->frame.
> > 
> > My opinion: It won't work to always remove objects which has data->frame ==
> > NULL in the cache on any frame cleanup, because that would influence
> > (invalidate) GObject-s from other web views (if there are more instances).
> 
> I think the actual bug are the gtk-doc tags used, because not all GObject
> DOM bindings are supposed to be returned as transfer-none. See the original
> bug #40302 and the commits message:
> 
> "Manual management (calling g_object_unref on them) is also allowed, and is
> required for objects that are not in the DOM tree (eg NodeLists)."
> 
> I forgot about those when I added the transfer annotations to the gtk-doc :-(

But there's still a problem. A lot of DOM objects are initially created and then added to a container, so they are not initially in document and we don't track their frame. I wonder if we should simply remove the inDocument check and always track the frame.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150216/ee35f66d/attachment-0002.html>