Bug 1326 – Garbage Collector dysfunction - Memory leak in gc_term() with DLLs - and more.

--- 1: Memory leak in gc_term() --- src/phobos/internal/gc/gc.gc_term() is missing a call to _gc.Dtor(). Without it, unloading a DLL doesn't release heap pages created by gc_init(); resulting in ~1.5MB being leaked each time a DLL is reloaded. Adding the _gc.Dtor() call to gc_term(), and rebuilding phobos seemed to solve the problem, but there may be more resources being leaked. The memory usage for a process still grows ~100k each time a dll is loaded+unloaded (better than before at least heh). Its possible this has to do with the std.thread.Thread.thread_init() call in gc_init; or something specific to my DLL - in anycase, it's something to consider. --- 2: setGCHandle / endGCHandle --- Calling setGCHandle() for a new DLL *without* manually calling std.thread.Thread.thread_init() causes newly created threads to crash. I dont think ive seen this documented anywhere. Also, endGCHandle() seems to fail at releasing memory associated with the DLL its called from. fullCollect() ends up referring to memory inside the unmapped DLL later on and seg-faulting. (The test case here has the GC running in its own DLL) --- 3: COM objects are being allocated on the GC heap --- class display : ComObject, public IDirect3D8 {}; Gets allocated on the GC heap. fullCollect() causes the program using it to seg-fault right away. The test in gc.d/_d_newclass() probably fails: if (ci.flags & 1){} // if COM object Manually allocating the object like this, or by overloading new/delete, causes it to function properly: ClassInfo info; void *obj = c_alloc(info.init.length); (cast(byte*)obj)[0 .. info.init.length] = info.init[];

I tried this with 3): ----------------------- import std.c.windows.com; interface I { } class Foo : ComObject, public I { } void main() { Foo f = new Foo(); } --------------------- and instrumented _d_newclass(). The test: if (ci.flags & 1){} // if COM object is triggered properly. If you could check it for your explicit case, that would be helpful, as I cannot reproduce the problem.

(In reply to comment #1) > I tried this with 3): > ----------------------- > import std.c.windows.com; > > interface I { } > > class Foo : ComObject, public I { } > > void main() > { > Foo f = new Foo(); > } > --------------------- > and instrumented _d_newclass(). The test: > if (ci.flags & 1){} // if COM object > is triggered properly. If you could check it for your explicit case, that would > be helpful, as I cannot reproduce the problem. > Ah yea, this one is my fault (ci.flags was 0b101). I wrongly assumed the GC would gc.addRange() the object for you - manually doing it fixed things. Sorry about that!

It looks like this is really 3 different bug reports, which is generally a bad idea. Are all three of them still bugs? Do you have actual reproduction code for each of them? Would you please file individual bugs for each case that's still a reproduceable bug and attach to each one code and steps to demonstrate it. Thanks, Brad

(In reply to comment #3) > It looks like this is really 3 different bug reports, which is generally a bad > idea. Are all three of them still bugs? Do you have actual reproduction code > for each of them? > > Would you please file individual bugs for each case that's still a > reproduceable bug and attach to each one code and steps to demonstrate it. > > Thanks, > Brad > Hopefully the changes to the GC structure in 2.06 solved problem #1 and #2 and http://d.puremagic.com/issues/show_bug.cgi?id=1360. I remember reading somewhere that Walter made gc_term() intentionally not free resources, assuming that the OS will take care of it when the program exits. Maybe he overlooked situations like #1. Does the GC still consume a foreign (possibly temporary) thread as its "main" and expects it to be active? Seems like thats asking for trouble if it does. Either way, ill try to update to 2.06 and make some test apps when i get some time.

Does this bug still exist with the switch to druntime?

The switch to druntime should have addressed issues #1 and #2. _gc.Dtor() is called in gc_term(), and the way GCs interact when loading DLLs has been reworked.

Looks like all of the issues have long since been resolved.