http://d.puremagic.com/issues/show_bug.cgi?id=1326

           Summary: Garbage Collector dysfunction  - Memory leak in
                    gc_term()  with DLLs - and more.
           Product: D
           Version: 2.002
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: patch
          Severity: critical
          Priority: P2
         Component: Phobos
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: wqeqweuqy@hotmail.com


--- 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[];


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1326





------- Comment #1 from bugzilla@digitalmars.com  2007-07-10 01:53 -------
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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1326





------- Comment #2 from wqeqweuqy@hotmail.com  2007-07-10 02:42 -------
(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!


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1326





------- Comment #3 from braddr@puremagic.com  2007-10-28 02:58 -------
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


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1326





------- Comment #4 from wqeqweuqy@hotmail.com  2007-10-28 23:15 -------
(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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1326


Brad Roberts <braddr@puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |braddr@puremagic.com




--- Comment #5 from Brad Roberts <braddr@puremagic.com>  2009-06-07 13:31:07 PDT ---
Does this bug still exist with the switch to druntime?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1326


Sean Kelly <sean@invisibleduck.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sean@invisibleduck.org




--- Comment #6 from Sean Kelly <sean@invisibleduck.org>  2009-06-16 21:42:26 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1326


Brad Roberts <braddr@puremagic.com> changed:

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


--- Comment #7 from Brad Roberts <braddr@puremagic.com> 2009-09-12 19:46:51 PDT ---
Looks like all of the issues have long since been resolved.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------