current GC behavior

[luka8088]

On 6.11.2012 21:59, Ali Çehreli wrote:
> On 11/06/2012 12:00 PM, luka8088 wrote:
>
>  > Yes, but it seems that we can in general say that the following code
>  > will never fail... or am I wrong ?
>  >
>  > import core.memory;
>  >
>  > class a {
>  > static int totalRefCount = 0;
>  > this () { totalRefCount++; }
>  > ~this () { totalRefCount--; }
>  > }
>  >
>  > void main () {
>  > assert(a.totalRefCount == 0);
>  > ({
>  > auto a1 = new a();
>  > assert(a.totalRefCount == 1);
>  > })();
>  > GC.collect();
>
> The current definition of GC.collect() explicitly says that its
> definition may change:
>
> http://dlang.org/phobos/core_memory.html#collect
>
> "the meaning of this may change based on the garbage collector
> implementation".
>
>  > assert(a.totalRefCount == 0);
>  > }
>  >
>  >>
>  >> In fact, some objects may never be collected even if there are no more
>  >> references to them.
>  >
>  > Can you give me an example ?
>
> I can't come up with an example but the spec is clear on that issue:
>
> http://dlang.org/class.html#destructors
>
> "The garbage collector is not guaranteed to run the destructor for all
> unreferenced objects. 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."
>
> Ali
>

I see, so is there some alternative for memory leak tests ?

Luka