[Issue 4092] broken memory management for COM objects derived from IUnknown

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=4092



--- Comment #4 from Rainer Schuetze <r.sagitario at gmx.de> 2011-02-08 00:41:49 PST ---
The problem with allocating COM objects from the C-heap is that they cannot be
free'd inside Release() due to possible invariants being called after that.

Here's the implementation of Release in std.c.windows.com:

    ULONG Release()
    {
        LONG lRef = InterlockedDecrement(&count);
        if (lRef == 0)
        {
            // free object

            // If we delete this object, then the postinvariant called upon
            // return from Release() will fail.
            // Just let the GC reap it.
            //delete this;

            return 0;
        }
        return cast(ULONG)lRef;
    } 

The comment even implies that the memory should be taken from the GC.

Also, any object that has references into other memory blocks needs to add
itself as a root to the GC, which can be very easily forgotten (e.g. if the
references are just strings).

As reported lately, the juno project
(http://www.dsource.org/projects/juno/wiki, probably the largest project trying
to embrace COM), works similar as proposed here. (
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=128956
)

Agreed, changing this might break some code, but probably most applications
creating COM objects have overloaded new anyway.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------