Tracing Open References To Dested Objects Preventing GC

[Josh Lang]

We appear to have an issue when we have longer reboots that some items that are destructed aren't being fully released, even by a GC, so our total object count goes sky high after ~10-14 days and we start to bog down the CPU.

We're on an older (ancient?) driver, 3.2.15 (in the process of migrating to 3.6.8 on a test port however).  Looking at /DEST_OBJ_DUMP tells me there's items with open references, but given that find_object() can no longer find any of them since they're already destructed, is there anyway to glean what those open references preventing GC from happening actually are? That's presuming I'm understanding the DEST_OBJ_DUMP correctly...

For instance:
players/necs/items/undead_spirit#14396849 ref  5

I believe that would be the file_name() and then indicating there's 5 current references to the object, even though its destructed and find_object(" players/necs/items/undead_spirit#14396849") returns 0, but I have no clue how to figure out what those 5 references are/could be?

It doesn't appear to be an issue on the 3.6.8 port as I can't replicate it there, but since our time table for migration isn't fully known yet, figured I'd ask if there's a good way for me to troubleshoot this on our outdated live version...