mirror of
https://github.com/Aurorastation/Aurora.3.git
synced 2026-07-27 07:46:54 +01:00
VMSolidus
6a8e7fec9a
Thanks to more extensive data from Sentry logging, I've discovered that there's actually two distinct causes for Hard Dels. 1. **Unaccounted For References**: Any potential references that are not nulled out during a Destroy() proc will eventually trigger a hard delete. These are the classic "Memory Leaks" and were previously the most common form of hard del. 2. **Poisoned Destroy()**: Some destroy procs are prone to runtime errors. When a runtime error occurs, the destroy() proc returns . instead of ..(), meaning all parents of an object will skip any reference cleanup they would have wanted to do. Since there's ref cleanup performed at every single step of a parent hierarchy all the way down to /datum itself, these failed Destroy() procs are nearly guaranteed to trigger a hard delete. For example, nearly all current /human related hard deletes are caused by this specific runtime error: https://github.com/Aurorastation/Aurora.3/pull/22680 So this PR adds a try catch to the garbage collector to log runtime errors generated by Destroy() procs, allowing me to far more easily track down this specific variant of harddel. --------- Signed-off-by: VMSolidus <evilexecutive@gmail.com>