Here's a useful hack for anyone using classes with "expensive" dtors. To
help track dtor calls from the GC add the following lines at line 301 of
src/phobos/internal/gc/gc.d (just inside new_finalizer)
 if (p && dummy == p) {
 ClassInfo **pc = cast(ClassInfo **)p;
 if (*pc) {
     for( ClassInfo c = **pc; c; c = c.base) {
            if (c.destructor) {
                printf("GC: ~%.*s(%p)\n",c.name,p);
                break;
            }
        }
    }
 }
and search through gcx.d for *finalizer and replace the null second
arguments with p and recompile phobos.
Then when your program runs you can watch for any print statements to see
just when your resources are getting cleaned up and if you need to worry
about manually managing the resource. For example the test code

class Foo {
    byte[100000] big;
    ~this(){}
}
int main() {
    while(true) {
        printf("allocating\n");
        new Foo;
        printf("done allocating\n");
    }
    return 0;
}

produces on my machine

allocating
done allocating
allocating
done allocating
allocating
done allocating
allocating
done allocating
allocating
done allocating
allocating
done allocating
allocating
done allocating
allocating
GC: ~Foo(00892000)
GC: ~Foo(008AB000)
GC: ~Foo(008C4000)
GC: ~Foo(008DD000)
GC: ~Foo(008F6000)
GC: ~Foo(0090F000)
GC: ~Foo(00928000)
GC: ~Foo(0095A000)
done allocating
allocating
done allocating
allocating
done allocating

while if I explicitly delete in main

int main() {
    while(true) {
        printf("allocating\n");
        Foo x = new Foo;
        printf("done allocating\n");
        delete x;
    }
    return 0;
}

it no longer prints any GC traces.

In article <dcqlg1$16jp$1@digitaldaemon.com>, Ben Hinkle says...
>
>Here's a useful hack for anyone using classes with "expensive" dtors. To help track dtor calls from the GC add the following lines at line 301 of src/phobos/internal/gc/gc.d (just inside new_finalizer)

Interesting idea.  Expand the output a bit to mention class name on construction plus the memory address the object is in for both and you could generate reports from the output to see which objects are never destroyed.  Too bad there's no easy way to get source file/line information in the display as well.


Sean

"Sean Kelly" <sean@f4.ca> wrote in message news:dcqn2s$17t2$1@digitaldaemon.com...
> In article <dcqlg1$16jp$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>Here's a useful hack for anyone using classes with "expensive" dtors. To help track dtor calls from the GC add the following lines at line 301 of src/phobos/internal/gc/gc.d (just inside new_finalizer)
>
> Interesting idea.  Expand the output a bit to mention class name on
> construction
> plus the memory address the object is in for both and you could generate
> reports
> from the output to see which objects are never destroyed.  Too bad there's
> no
> easy way to get source file/line information in the display as well.

It might be possible to hook into the LOGGING version in gcx that is used for leak detection. I haven't recompiled with logging, though, so I don't know anything about it besides glancing through the code. It's true that it can be surprising what stuff hangs around from some non-obvious global reference.