www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1326] New: Garbage Collector dysfunction - Memory leak in gc_term() with DLLs - and more.

reply d-bugmail puremagic.com writes:
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[];


--
Jul 09 2007
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1326






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.


--
Jul 09 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1326








 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! 


--
Jul 10 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1326






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


--
Oct 28 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1326








 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=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.


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.


--
Oct 28 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1326


Brad Roberts <braddr puremagic.com> changed:

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





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: -------
Jun 07 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1326


Sean Kelly <sean invisibleduck.org> changed:

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





PDT ---

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: -------
Jun 16 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1326


Brad Roberts <braddr puremagic.com> changed:

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



---
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: -------
Sep 12 2009