https://issues.dlang.org/show_bug.cgi?id=19119

kinke@gmx.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kinke@gmx.net

--- Comment #1 from kinke@gmx.net ---
Confirmed. It's the 3rd iteration only because GC collection is triggered then; adding `import core.memory; GC.collect();` after destroy makes it segfault in the 1st iteration, as does using `delete(bar);` instead of destroy.

I guess there's something wrong with the dtor field of the ClassInfo.

--

https://issues.dlang.org/show_bug.cgi?id=19119

--- Comment #2 from kinke@gmx.net ---
Nope, druntime apparently doesn't support destroying C++ classes yet. E.g.,
_d_delclass() and rt_finalize2() assume D objects, where the ClassInfo is
stored in the first vtable slot. rt_finalize2() also assumes an implicit
monitor field etc.

--

https://issues.dlang.org/show_bug.cgi?id=19119

alexanderheistermann@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alexanderheistermann@gmail.
                   |                            |com, turkeyman@gmail.com

--

https://issues.dlang.org/show_bug.cgi?id=19119

--- Comment #3 from Manu <turkeyman@gmail.com> ---
I never tested the new extern(C++) work with the GC.

destroy() knows how to destroy a C++ class because it knows the argument type, but the GC collect doesn't know the type, and can't know the memory is a C++ class and how to destroy it properly.

I'm not sure what options are possible in this case.

I reckon, if you're using C++ classes, use C++ allocation strategies.

--

https://issues.dlang.org/show_bug.cgi?id=19119

--- Comment #4 from Manu <turkeyman@gmail.com> ---
It might be possible to make gcnew detect it's allocating a C++ class, and allocate it wrapped in a thin D class for the classinfo, and forward the D destructor to the C++ destructor...?

--

https://issues.dlang.org/show_bug.cgi?id=19119

--- Comment #5 from Vladimir Marchevsky <vladimmi@gmail.com> ---
Sorry if it's not useful, just want to point out couple of things from my perspective as language newcomer that may hint something for you:

1) Example in ticket works when Foo::~Foo is not virtual. So does in that case D know how to destroy CPP classes and is it "virtual" causing some troubles?

2) Example in ticket also works in other case - Foo::~Foo is virtual but Foo doesnt contain Bar. Why implementation details (Bar isnt even exported and mapped in D) do some changes to behavior?

--

https://issues.dlang.org/show_bug.cgi?id=19119

--- Comment #6 from anonymous4 <dfj1esp02@sneakemail.com> ---
Shouldn't you declare class fields on the D side? How one can determine how much memory to allocate for the instance?

--

https://issues.dlang.org/show_bug.cgi?id=19119

--- Comment #7 from Vladimir Marchevsky <vladimmi@gmail.com> ---
Sounds logical. I've tried to additionally export Bar, map it in D and also to add Foo::a and Foo::b to mapping to make it full. Problem has gone and it seems to work correct without crashes or memory leaks.

But how does it happen to work under some conditions before (like with non-virtual dtor)? Does "virtual" change used methods to create/delete objects somehow or was that sort of random luck?..

--

https://issues.dlang.org/show_bug.cgi?id=19119

--- Comment #8 from Manu <turkeyman@gmail.com> ---
(In reply to Vladimir Marchevsky from comment #7)
> Sounds logical. I've tried to additionally export Bar, map it in D and also to add Foo::a and Foo::b to mapping to make it full. Problem has gone and it seems to work correct without crashes or memory leaks.

Yeah, sorry, I didn't notice that the classes were not matching!
If you're going to allocate instances of a class, they need to be the same
size.

> But how does it happen to work under some conditions before (like with non-virtual dtor)? Does "virtual" change used methods to create/delete objects somehow or was that sort of random luck?..

You were lucky. The CPP ctor/dtor were assigning and destroying a,b which were
outside of the memory allocation (since you didn't define them in the class
that D allocated.
It's likely that there's a minimum allocation granularity (like 16 bytes or
something) and those members just happened to fit inside... but when you added
the vtable, the class got bigger, maybe b was outside of the minimum allocation
block... or lots of possibilities. You were writing to unallocated memory;
anything could happen!

--

https://issues.dlang.org/show_bug.cgi?id=19119

--- Comment #9 from kinke@gmx.net ---
Ouch, I totally overlooked the missing fields on the D side too.

The GC now releases the memory correctly - without trying to destruct the
extern(C++) objects first (independent from virtual-ness of dtor), which might
be an issue in its own right.

--