Summary: | [ATK] Leak: AtkRelationSet is not freed | ||
---|---|---|---|
Product: | WebKit | Reporter: | Brian Holt <brian.holt> |
Component: | Accessibility | Assignee: | Nobody <webkit-unassigned> |
Status: | UNCONFIRMED --- | ||
Severity: | Normal | CC: | bugs-noreply, mario |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Linux | ||
Bug Depends on: | |||
Bug Blocks: | 116317 |
Description
Brian Holt
2013-07-11 08:28:38 PDT
This seems to happen because the reference count of the target of the AtkRelation (an AtkObject) increases as result of caching. (In reply to comment #1) > This seems to happen because the reference count of the target of the > AtkRelation (an AtkObject) increases as result of caching. Yes, that is my guess as well. Since the memory allocated in this malloc happens because of being the first call to g_object_weak_ref() over that AtkRelation object (and not just because it should happen every time you call g_object_weark_ref()), that memory can't be released at the very same (future) moment when you call g_object_weak_unref(), since that might be causing problems. Instead, that memory will be released when that AtkRelation object's ref count gets to zero, by means of the g_datalist_clear_data() function, which we double-checked it's what's will happen So the point is why the object's ref_count is not getting down to zero, and I agree with Brian that probably is because of one cache retaining that object alive. Question is whether that cache is AXObjectCache, the cache in the Atk bridge or something else, and whether that's a problem (design issue in those caches?) or not. Thus, let's keep this bug open since it will help remind us that there's something here, probably related to caches, that might require further investigation. |