Thread overview
[Issue 6666] New: gc finalization/freeing is hierarchy agnostic
Sep 14, 2011
dawg@dawgfoto.de
Sep 14, 2011
Vladimir Panteleev
Sep 14, 2011
Vladimir Panteleev
Sep 14, 2011
dawg@dawgfoto.de
September 14, 2011
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: -------
September 14, 2011
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: -------
September 14, 2011
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: -------
September 14, 2011
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: -------