www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1434] New: DMD COM design flaw

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1434

           Summary: DMD COM design flaw
           Product: D
           Version: 2.004
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: blocker
          Priority: P1
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: davidl 126.com


import std.stdio;
interface IUnknown
{
}
class k:IUnknown 
{
    invariant
    {
        writefln("hello");
    }
    this()
    {
        writefln("this class!");
    }
    void hello()
    {
        writefln("this class!");
    }
}
void main()
{
    k v=new k;
    Object o=v;
    ClassInfo c = o.classinfo;
    int *m=cast(int*)(&c.classInvariant); 
    *m= 1;
    v.hello();
}

consider "v" is a COM object returned from any C code.
so how can we assume its invariant field still hold the correct value?
The last call which would trigger an access violation


--
Aug 20 2007
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1434






For most cases classes which implement IUnknown would surely be an com object,
it would surely use a Windows API to get from outside code. The solution would
be when a call to IUnknown/IUnknown inherited class , the invariant check goes
away.


--
Aug 20 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1434






This bug blocks DFL clipboard in somecases(when C code modifies that specific
field). 


--
Aug 20 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1434






the following is a bit more clear:

import std.stdio;
interface IUnknown
{
        void hello();
}
class k:IUnknown 
{
        invariant
        {
                writefln("hello");
        }
        this()
        {
                writefln("this class!");
        }
        void hello()
        {
                writefln("this class!");
        }
}
void main()
{
// following only illustrate the C side instantiating a COM object
        k v=new k;
        Object o=v;
        ClassInfo c = o.classinfo;
        int *m=cast(int*)(&c.classInvariant); 
        *m= 1;
// now we can a COM object , we call through our interface
        IUnknown t=v;
        t.hello();   // invariants calling?? C side code could ruin the field
like the code above
}


--
Aug 20 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1434


bugzilla digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID





The way to write com objects in D is to use:

import std.windows.iunknown;

to get IUnknown. Don't write your own, it won't work. Also, of course if you
stomp on the pointer to the classInvariant, it'll crash when it's called.

I don't really understand the issue here. I'll mark it as invalid for the
moment. Please fix the example code, and reopen if there's still a problem.


--
Aug 30 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1434


davidl 126.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |





The problem here is simple. D caller who accesses a COM object which can be
created at the C side can never assume the ClassInfo area valid. ClassInfo of a
COM object makes nosense thus the invariant calling is invalid


--
Sep 01 2007
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1434


davidl 126.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID





invariant thing is the first thing trigger the drag & drop bug.
But it's not the DMD fault.
The classinfo field is not from COM object either. 
From the discussion with miller, he says the problem is the GC collected the
object too early. So that could be the problem of making the invariant field
changed from null to some pointer, thus access violatoin 


--
Sep 15 2007