www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6666] New: gc finalization/freeing is hierarchy agnostic

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6666

           Summary: gc finalization/freeing is hierarchy agnostic
           Product: D
           Version: D2
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: druntime
        AssignedTo: nobody puremagic.com
        ReportedBy: dawg dawgfoto.de


--- Comment #0 from dawg dawgfoto.de 2011-09-13 17:58:47 PDT ---
class A
{
    ~this() {}
    void cleanup() {}
}

class B
{
    this(A a) { this.a = a; }
    ~this() { a.cleanup(); }
    A a;
}

void main() {
    auto a = new A();
    auto b = new B(a);
    // allocating a at a lower address than b causes it to be finalized earlier
    assert(cast(void*)b.a < cast(void*)b);
}
---

Finalization is done in memory order and does not take
hierarchies into account.
When b.a is finalized before b it's vtable is set to null, hence
a segfault will happen when accessing the vtable.
Anyhow a is destroyed before b even though it is referenced by b.

It seems like we need to somehow sort the to be finalized memory while
scanning.
Any cheap ideas to do that are welcome.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 13 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6666


Vladimir Panteleev <thecybershadow gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thecybershadow gmail.com


--- Comment #1 from Vladimir Panteleev <thecybershadow gmail.com> 2011-09-13
18:04:22 PDT ---
This is known, documented behavior. From
http://www.d-programming-language.org/class.html#destructors :


 Furthermore, the order in which the garbage collector calls destructors for
unreference objects is not specified. This means that when the garbage
collector calls a destructor for an object of a class that has members that are
references to garbage collected objects, those references may no longer be
valid. This means that destructors cannot reference sub objects.


(In reply to comment #0)

 It seems like we need to somehow sort the to be finalized memory while
 scanning.


What about cyclic references?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 13 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6666



--- Comment #2 from Vladimir Panteleev <thecybershadow gmail.com> 2011-09-13
18:05:56 PDT ---
Oops, I broke it.


 Furthermore, the order in which the garbage collector calls destructors
 for unreference objects is not specified. This means that when the garbage
 collector calls a destructor for an object of a class that has members that
 are references to garbage collected objects, those references may no longer
 be valid. This means that destructors cannot reference sub objects.


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 13 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6666


dawg dawgfoto.de changed:

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


--- Comment #3 from dawg dawgfoto.de 2011-09-13 21:18:40 PDT ---
Surprise, surprise.
Seems like there is not much one can reliably do in a finalizer.
Anyhow it was motivated by a C++ habit to do some clean up.

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