[Webkit-unassigned] [Bug 40302] New: [GTK] Memory managament for DOM GObject wrappers

[bugzilla-daemon at webkit.org]

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

           Summary: [GTK] Memory managament for DOM GObject wrappers
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Mac OS X 10.5
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: xan.lopez at gmail.com


When a GObject DOM object is created we wrap the core DOM object (say, WebCore::Node) with a native GObject, add a manual C++ ref to the core object, and place the matching deref in the finalize method (note to self, this should probably be done in dispose). So far, this seems sane.

Problem is, before returning the object we do the following: we place the object in a hash map, indexed by the core object, and if a wrapper for this core object is requested again we'll just return the corresponding GObject as-is. This entry in the hash map is, also, cleared on finalize. Since we do not add extra references in this process, you can get into a situation where you have two pointers to a GObject DOM binding that are actually the same object, with only one total reference; if you do g_object_unref on objects you don't need, tragedy will ensue when you try to use the second pointer (even if it's only to also unref it).

The hash map concept seems very reasonable to me in general, so I think what we should do is to always add a new reference when we return an object, even if we are only getting it from the map. This way the rule "always unref DOM objects when you are done with them" will work.

The only remaining problem would be the huge pain in the ass that this kind of API is for C programmers, of course...

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.