How to debug (potential) GC bugs?

[Marco Leise via Digitalmars-d-learn]

Am Sun, 25 Sep 2016 16:23:11 +0000
schrieb Matthias Klumpp <matthias at tenstral.net>:

> So, I would like to know the following things:
> 
> 1) Is there any caveat when linking to C libraries and using the 
> GC in a project? So far, it seems to be working well, but there 
> have been a few cases where I was suspicious about the GC 
> actually doing something to malloc'ed stuff or C structs present 
> in the bindings.

If you pass callbacks into the C code, make sure they never
throw. Stack unwinding and exception handling generally
doesn't work across language boundaries.

A tracing garbage collector starts with the assumption that
all the memory that it allocated is no longer reachable and
then starts scanning the known memory for any pointers to
allocations that falsify this assumption.
What you malloc'ed is unknown to the GC and wont be scanned.
Should you ever have GC memory pointers in your malloc'ed
stuff, then you need to call GC.addRange() to make those
pointers keep the allocations alive. Otherwise you will get a
"used after free" error: data corruption or access violations.
A simple case would be a string that you constructed in D and
store in C as a pointer. The GC can automatically scan the
stack and any globals/statics on the D side, but that's about
it.

I know of no tools similar to valgrind specially designed to
debug the D GC. You can plug into the GC API and keep track of
the allocation sizes. I.e. write a proxy GC.

-- 
Marco