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
Comment #1 by davidl — 2007-08-20T03:56:37Z
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.
Comment #2 by davidl — 2007-08-20T03:58:58Z
This bug blocks DFL clipboard in somecases(when C code modifies that specific field).
Comment #3 by davidl — 2007-08-20T04:41:36Z
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
}
Comment #4 by bugzilla — 2007-08-30T13:44:48Z
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.
Comment #5 by davidl — 2007-09-01T09:06:53Z
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
Comment #6 by davidl — 2007-09-15T08:59:46Z
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