How to debug (potential) GC bugs?

[Guillaume Piolat via Digitalmars-d-learn]

On Sunday, 25 September 2016 at 16:23:11 UTC, Matthias Klumpp 
wrote:
> Hello!
> I am working together with others on the D-based 
> appstream-generator[1] project, which is generating software 
> metadata for "software centers" and other package-manager 
> functionality on Linux distributions, and is used by default on 
> Debian, Ubuntu and Arch Linux.
>
> For Ubuntu, some modifications on the code were needed, and 
> apparently for them the code is currently crashing in the GC 
> collection thread: http://paste.debian.net/840490/
>
> The project is running a lot of stuff in parallel and is using 
> the GC (if the extraction is a few seconds slower due to the GC 
> being active, it doesn't matter much).
>
> We also link against a lot of 3rd-party libraries and use a big 
> amount of existing C code in the project.
>
> 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.

There is no way the GC scans memory allocated with malloc (unless 
you tell it to) or used in the bindings.
A caveat is that if you are called from C (not your case), you 
must initialize the runtime, and attach/detach threads.

The GC could well stop threads that are currently in the C code 
if they were registered to the runtime.


> 2) How can one debug issues like the one mentioned above 
> properly? Since it seems to happen in the GC and doesn't give 
> me information on where to start searching for the issue, I am 
> a bit lost.

There can be multiple reasons.
   - The GC is collecting some object that is unreachable from its 
POV; when you are actually using it.
   - The GC is calling destructors, that should not be called by 
the GC. Performing illegal operations. usually this is solved by 
using deterministic destruction instead and never relying on a 
destructor called by the GC.
   - The GC tries to stop threads that don't exist anymore or are 
not interruptible

My advice is to have a fuly deterministic tree of objects, like a 
C++ program, and Google for "GC-proof resource class" in case you 
are using classes.