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

https://issues.dlang.org/show_bug.cgi?id=4092 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --

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

https://issues.dlang.org/show_bug.cgi?id=4092 Andrei Alexandrescu changed: What|Removed |Added Version|unspecified |D2 --

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

http://d.puremagic.com/issues/show_bug.cgi?id=4092 --- Comment #15 from Andrej Mitrovic 2013-09-28 04:20:28 PDT --- (In reply to comment #9) > The patch in druntime would make this obsolete. This issue really does need to be resolved, e.g. the newCom function can't be used for COM classes wit

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

http://d.puremagic.com/issues/show_bug.cgi?id=4092 --- Comment #14 from Rainer Schuetze 2013-09-27 13:52:28 PDT --- The reference count might be slightly different than what's used in a language without GC, but I think starting at 0 is appropriate here. The object pointer can be used by the D

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

http://d.puremagic.com/issues/show_bug.cgi?id=4092 --- Comment #12 from Rainer Schuetze 2013-09-27 13:31:42 PDT --- (In reply to comment #11) > Hmm, you seem to have this prototype in that file: > > extern(C) void* gc_malloc(size_t sz, uint ba = 0, const TypeInfo ti=null); This is the proto

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

http://d.puremagic.com/issues/show_bug.cgi?id=4092 --- Comment #13 from Andrej Mitrovic 2013-09-27 13:33:33 PDT --- (In reply to comment #12) > This is the prototype for the precise GC, but it should do no harm elsewhere > because the additional parameter in an extern(C) function is ignored by

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

http://d.puremagic.com/issues/show_bug.cgi?id=4092 --- Comment #11 from Andrej Mitrovic 2013-09-27 09:00:44 PDT --- > (In reply to comment #9) > https://github.com/D-Programming-Language/visuald/blob/master/stdext/com.d#L28 Hmm, you seem to have this prototype in that file: extern(C) void* g

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

http://d.puremagic.com/issues/show_bug.cgi?id=4092 --- Comment #10 from Andrej Mitrovic 2013-09-27 08:56:35 PDT --- (In reply to comment #9) > https://github.com/D-Programming-Language/visuald/blob/master/stdext/com.d#L28 Nice, this will be useful for me. Thanks. -- Configure issuemail: htt

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

http://d.puremagic.com/issues/show_bug.cgi?id=4092 --- Comment #9 from Rainer Schuetze 2013-09-27 08:33:05 PDT --- > Actually `atomicOp!"+="(count, 1)` could be used as well, no? Yes, that would be better than a synchronized block. > Also, this can actually now be: > return GC.malloc(size, G

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

http://d.puremagic.com/issues/show_bug.cgi?id=4092 --- Comment #8 from Andrej Mitrovic 2013-09-27 07:16:42 PDT --- (In reply to comment #5) > void* p = gc_malloc(size, 1); // BlkAttr.FINALIZE Also, this can actually now be: return GC.malloc(size, GC.BlkAttr.FINALIZE); -- Configure

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

http://d.puremagic.com/issues/show_bug.cgi?id=4092 --- Comment #7 from Andrej Mitrovic 2013-09-27 07:11:21 PDT --- (In reply to comment #6) > Can a a synchronized block be used instead? Actually `atomicOp!"+="(count, 1)` could be used as well, no? -- Configure issuemail: http://d.puremagic.

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

http://d.puremagic.com/issues/show_bug.cgi?id=4092 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comme

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

http://d.puremagic.com/issues/show_bug.cgi?id=4092 --- Comment #5 from Rainer Schuetze 2011-02-15 23:18:19 PST --- Overloading new seems to do the job without the patch in the runtime, so here is my current implementation of COM objects: extern (C) void* gc_malloc( size_t sz, uint ba = 0 );

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

http://d.puremagic.com/issues/show_bug.cgi?id=4092 --- Comment #4 from Rainer Schuetze 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 implementati

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

http://d.puremagic.com/issues/show_bug.cgi?id=4092 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #

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

http://d.puremagic.com/issues/show_bug.cgi?id=4092 Trass3r changed: What|Removed |Added CC||mrmoc...@gmx.de --- Comment #2 from Trass3r

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

http://d.puremagic.com/issues/show_bug.cgi?id=4092 --- Comment #1 from Rainer Schuetze 2010-05-01 00:14:19 PDT --- I just recently noticed, that AddRef and Release should use addRoot and removeRoot, not addRange and removeRange. -- Configure issuemail: http://d.puremagic.com/issues/userprefs