Is there some way to get the reference count of and/or objects or ref address (like the /ref text macro) that reference a particular object (or even the specific variables that reference that object)? If not, can we get such a feature?
Basically, show some of what del() is doing under the hood.
I've tried making my own softcoded methods, but those don't catch everything, particularly images.
It'd make it easier to find memory leaks, as I don't particularly enjoy using del(), but sometimes I may miss a thing or two. Thanks in advance.
ID:2082517
 May 11 2016, 1:44 am
|
|||||||
Not Feasible
| |||||||
|
May 11 2016, 2:51 am
|
|
GinjaNinja32
 |
+1, this would potentially be useful for debugging qdel() failures if it explained what objects referenced another object.
|
+1, even just a read-only var for the refcount would be wonderful.
| |
Lummox JR resolved issue (Not Feasible)
| |
This isn't possible.
The garbage collector runs loops as tight as it possibly can, and at the point a matching reference is detected, it doesn't have any information about where the reference was. Passing that info, or setting it up in a global var that could be used on detection, would be a severe strain on the loop and would make regular del() cases behave much, much worse. | |
What if such a thing we're only available of DEBUG were enabled, so you could get better debugging info at the cost of performance?
| |
Popisfizzy wrote:
What if such a thing we're only available of DEBUG were enabled, so you could get better debugging info at the cost of performance? Not possible, because the checks for that would have to happen at each point within the loop, not just as a one-time thing. The same performance-killing problem applies. | |
There's not even a pointer that it can pass to a JIT debugger or something?
Okay, so how about a way to detect all images and datums (or even every living thing) in a world? That has to be available somewhere, no? That way we can make our own softcoded versions that don't only contain mobs/objs/areas/turfs. Or even a separate BYOND application build or dll that BYOND can use. Say we call it references.dll. BYOND comes with a references.dll and a references_debug.dll. The references.dll just implements functions that do nothing, while the reference_debug.dll does the performance-killing stuff. The GC calls the functions in references.dll. In order to use the detection, rename references_debug.dll to references.dll. The build idea would just be a version of Dream Daemon with this stuff included, but just in a separate exe, or a separate zip file entirely. EDIT: Okay, I got all images that are variables down, and I'm pretty sure all my images are variables. Now let's see if I can get any lingering datums... EDIT_2: Yeah, I think I only have one datum that is global. I can't find what is referencing this mob. It has no key, no tag, no looping functions, nothing. It just won't delete without del. There must be something I'm missing. Okay, I removed everything from the mob and still no dice. This makes no sense: all my other mobs kill themselves gracefully. | |
Does that mob have a key var set? A mob with a key has a reference. Also anything with a tag has a reference.
| |
No, it has no key, no tag, not even a looping function that would make it still have a reference to src.
| |
Is it possibly referenced in a local var in a proc that's sleeping?
| |
If it is, I don't know about it and the profiler is not showing it.
EDIT: Hah, it was usr causing the issue. How annoying, I wasn't using usr at all, but it was still there from the creation of an object in the Click() proc. But now I have other objects not deleting that I didn't see before. Sigh, the search never ends. | |