Hey, I'm Lemon, I work to fix hard deletes (del() calls caused by objects failing to free on their own) for the /tg/ fork of ss13.
I've gotten the count quite low, but there's still some that I can't reproduce locally. We have a tool that scans the world for refs, but it's quite slow, since it needs to check everywhere even if all refs were found or if the ref was cleared by some player action. https://github.com/tgstation/tgstation/blob/master/code/ modules/admin/view_variables/reference_tracking.dm
I can only use it on live in spurts because of this lack of speed and OOM concerns that happen mostly at highpop.
Being able to notice when all references are found, or hell knowing if we missed anything at the end would be amazing, and would aid my work significantly. Some form of read only reference count would be amazing for this.
This concept has been brought up before, but it was as a part of a more general "Reference finder" tool, and didn't really get discussed. Would it be feasible?
ID:2706489
 Aug 7 2021, 3:57 pm
|
|||||||
Resolved
| |||||||
If you mean observing patterns in what typepaths fail to clean up, that's already something we do. Trouble is I've already gotten rid of the majority of simple failures. What remains is things that fail due to some level of player action, which makes detecting and fixing these issues very troublesome
I understand that by its nature, accessing a var like that would never lead to 0 references. Is the amount of temporary references inconsistent? I guess even if they're the same each time if you do the same things it doesn't really make a good language feature since the usecase is pretty much just what I'm doing. | |
The number of temporary references would probably not be inconsistent so much as difficult to predict. There would be ways for such references to build up.
The only way I could conceive of this working would be if such a proc deliberately cleared out all temporary references within the current running proc, and only stuck with args. In theory I think that would be fine, and then you should see a value like 1 if the object is going to be deleted as soon as the var used for the call is cleared. But that's a bit overcomplicated. | |
See the thing is that's pretty much exactly my usecase, it's just not something that other people are likely to do
| |
Isn't this closeable now?
| |
Spevacus resolved issue with message:
As explained in id:2772176, refcount() has been added, which returns the number of references for a given object. | |
It seems to be the easier approach here is to look for objects that appear to be stacking up over time by type; that should be much simpler to do, and it will point out problem areas of the code much better.