code/controllers/subsystem/garbage.dm

Debugging GC issues In order to debug `qdel()` failures, there are several tools available. To enable these tools, define `TESTING` in _compile_options.dm. First is a verb called "Find References", which lists every refererence to an object in the world. This allows you to track down any indirect or obfuscated references that you might have missed. Complementing this is another verb, "qdel() then Find References". This does exactly what you'd expect; it calls `qdel()` on the object and then it finds all references remaining. This is great, because it means that `Destroy()` will have been called before it starts to find references, so the only references you'll find will be the ones preventing the object from `qdel()`ing gracefully. If you have a datum or something you are not destroying directly (say via the singulo), the next tool is `QDEL_HINT_FINDREFERENCE`. You can return this in `Destroy()` (where you would normally `return ..()`), to print a list of references once it enters the GC queue. Finally is a verb, "Show qdel() Log", which shows the deletion log that the garbage subsystem keeps. This is helpful if you are having race conditions or need to review the order of deletions. Note that for any of these tools to work `TESTING` must be defined. By using these methods of finding references, you can make your life far, far easier when dealing with `qdel()` failures.
/datum/qdel_item	Qdel Item: Holds statistics on each type that passes thru qdel
/proc/qdel	Should be treated as a replacement for the 'del' keyword.

Debugging GC issues

In order to debug qdel() failures, there are several tools available. To enable these tools, define TESTING in _compile_options.dm.

First is a verb called "Find References", which lists every refererence to an object in the world. This allows you to track down any indirect or obfuscated references that you might have missed.

Complementing this is another verb, "qdel() then Find References". This does exactly what you'd expect; it calls qdel() on the object and then it finds all references remaining. This is great, because it means that Destroy() will have been called before it starts to find references, so the only references you'll find will be the ones preventing the object from qdel()ing gracefully.

If you have a datum or something you are not destroying directly (say via the singulo), the next tool is QDEL_HINT_FINDREFERENCE. You can return this in Destroy() (where you would normally return ..()), to print a list of references once it enters the GC queue.

Finally is a verb, "Show qdel() Log", which shows the deletion log that the garbage subsystem keeps. This is helpful if you are having race conditions or need to review the order of deletions.

Note that for any of these tools to work TESTING must be defined. By using these methods of finding references, you can make your life far, far easier when dealing with qdel() failures.

/datum/qdel_item Qdel Item: Holds statistics on each type that passes thru qdel

/proc/qdel Should be treated as a replacement for the 'del' keyword.