Objects left to be garbage collected get passed through Del() anyways

ID:1776493
 
Feb 2 2015, 5:03 am
(See the best response by Kaiochao.)
Code:
runtime error: OH SHIT FIRE GOT DELETED?
proc name: Del (/atom/movable/Del)
  source file: atoms.dm,43
  usr: null
  src: the fire (/obj/fire)
  call stack:
the fire (/obj/fire): Del()
the fire (/obj/fire): Del()
lighting (/datum/controller/process/lighting): doWork()
lighting (/datum/controller/process/lighting): process()
/datum/controller/processSched... (/datum/controller/processScheduler): runProcess(lighting (/datum/controller/process/lighting))


Problem description:
One of my project's developers a year ago made a system to easily setup movables for garbage collection and we have a system of logging those that still have dangling refs or just existing still for whatever reason. Now to figure out what things aren't being put through the garbage controller i've setup a delete logger but this poses an issue because things that I know are being properly garbage collected are showing up in the delete log. The DM above is a callstack that i setup to happen when fire was hard deleted. The call stack doesn't make a damn bit of sense as its completely unrelated to fire and the lighting controller doesn't call del anywhere.

Is this an issue of byond being byond or user error.
Feb 2 2015, 6:35 am
Best response
The "del object" instruction does a lot more than simply calling object.Del(). The reason to use garbage collection is to avoid those other things. If an object simply disappeared without having Del() called, then you wouldn't need Del() to begin with.
Feb 2 2015, 8:19 am
Okay I understand that Del() does a hard lookup for hanging refs to the atom, but are you saying it is intended that a atom that has nothing referencing it other than world.contents will still have Del() called on it when the garbage collection system frees up that reference?
Feb 2 2015, 8:25 am
In response to Pomf123
Pomf123 wrote:
Okay I understand that Del() does a hard lookup for hanging refs to the atom,
I'm saying Del() doesn't do that, which is why it's still called.

The "del" instruction does all that reference-clearing and proc-killing. It's in the DM Reference.
Feb 2 2015, 10:23 am
You can think of the Del() proc as an "on delete" event handler. (Though always, always call ..() in it.) It is not responsible for deleting the atom; it's called when the atom is deleted, whether by the del instruction or the garbage collector.
Feb 2 2015, 10:29 am
Alright, that's a good explanation, thanks lummox. All this time I assumed that Del() and del were interchangeable.