https://issues.dlang.org/show_bug.cgi?id=1164

--- Comment #14 from Pieter Penninckx <pieter.penninckx@scarlet.be> ---
(In reply to comment #11)

Woops. You're right. The segfault is caused by an infinite recursion and probably not by a GC problem. We can avoid the infinite recursion by marking fun() as private:

class X
{
    X sibling;
    private bool fun() const { return true;    } // Note: this line changed.
    invariant() {
        if(sibling !is null) {
            if (sibling.fun()) { assert(true); }
        }
    }
    this() {sibling = new X(this); }
    this(X sibling_) {sibling = sibling_;}
    ~this() {}
}

int main() {
    X x = new X();
    return 0;
}

This just runs normally for me. But if I understand comment #13 correctly, this is just luck and I shouldn't count on it, especially when the runtime is compiled with the MEMSTOMP option.

--

https://issues.dlang.org/show_bug.cgi?id=1164

--- Comment #15 from safety0ff.bugz <safety0ff.bugz@gmail.com> ---
(In reply to Pieter Penninckx from comment #14)
>
> This just runs normally for me. But if I understand comment #13 correctly, this is just luck and I shouldn't count on it, especially when the runtime is compiled with the MEMSTOMP option.

MEMSTOMP is essentially a tool used for debugging memory corruption type
issues.
Compliant D code runs correctly regardless whether it is enable and I was using
it as an illustration of what is allowed in the runtime.

I don't know what is the official stance on referencing other GC managed memory
from invariant code.
Since it is automatically run before the destructor/finalizer, it violates the
spec.
This restriction is quite severe, it might be better if invariants aren't
called before the destructor.

--

https://issues.dlang.org/show_bug.cgi?id=1164

Dmitry Olshansky <dmitry.olsh@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmitry.olsh@gmail.com
            Summary|Wrong order of memory       |Unordered GC finalization
                   |deallocation                |leading to memory bugs

--

https://issues.dlang.org/show_bug.cgi?id=1164

Mathias LANG <pro.mathias.lang@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |pro.mathias.lang@gmail.com
         Resolution|---                         |WONTFIX

--- Comment #16 from Mathias LANG <pro.mathias.lang@gmail.com> ---
We advertise everywhere that you should not access GC-allocated items in destructors, but you can access anything that is allocated with another method. Just like you should not allocate in destructors.

Closing this, as it is not actionable.
Anything addressing this should be a DIP, as we have gathered over a decade of
experience with this problem.

--