Yet Another Question About Leaks

[Zeatherann]

Does assignment leak in the sense provided below? I know the no longer referenced trigger leaks.

function main takes nothing returns nothing
    local trigger SomeTrigger=CreateTrigger()
    // Do something with SomeTrigger.
    // The real question is; do I need to null out SomeTrigger before assigning to another object?
    set SomeTrigger=CreateTrigger()
    // Do something with the new trigger.
    set SomeTrigger=null
endfunction

 

[deathismyfriend]

If you mean something like this.

function main takes nothing returns nothing
    local trigger SomeTrigger=CreateTrigger()
    // Do something with SomeTrigger.
    // The real question is; do I need to null out SomeTrigger before assigning to another object?
    set SomeTrigger=CreateTrigger()
    // Do Something
    set SomeTrigger=CreateTrigger()
    // Do Something
    set SomeTrigger=CreateTrigger()
    // Do Something
    set SomeTrigger=CreateTrigger()
    // Do Something
    set SomeTrigger=CreateTrigger()
    // Do Something
    set SomeTrigger=CreateTrigger()
    // Do something with the new trigger.
    set SomeTrigger=null
endfunction

Then no it does not leak as long as you null the trigger at the end of the function.

 

[Zeatherann]

Sweet, this saves having to double assign. Thanks.

 

[IcemanBo]

If you will never destroy any of these created triggers, you even don't have to null the local variable at the end.

 

[Zeatherann]

Oh? Why not?

 

[PurgeandFire]

Oh? Why not?

Nulling is just a cleaning measure for when objects are destroyed:

(1) Object is destroyed, remove object from memory
(2) Blizzard checks: are there any local variable references pointing to this object? If so, do not free the handle ID. If not, then free the handle ID so it can be used again.
(3) ... some other memory management ...

... not necessarily in that order, but you get the gist. Imagine that each object in memory has an associated reference count and handle ID. Whenever a local points to it, that reference count is incremented. Whenever a local is reassigned or set to null, that reference count is decremented. It will only free the handle ID if the reference count is 0.

How much of an issue is this? It isn't as bad as a standard memory leak. The actual object's memory is mostly removed, but some extra stuff remain, e.g. the handle ID.

Logically, if you are never going to destroy an object, you don't need to null any of its pointers. You can let the reference count increment as much as you want, there isn't really any point to it if you'll never destroy it.

Note that this only applies to agents*. Agents are defined as reference-counted object types (if you see the common.j, that is how Blizz defines it). Regular non-agent handles, such as texttags or lightning, do not need to be nulled at all (and they won't suffer the handle ID issue!). Some permanent types do not need to be nulled either, such as players (you can't ever destroy a player).

*There might be one or two types that are not defined as agents in the common.j but actually are reference counted. For example, triggeraction is reference counted, even though it extends handle.

-----
But ultimately, keeping track of what you should null and what you shouldn't is tedious and complex. You can feel free to null all things as a safety measure. It won't add much overhead anyway, since assignment to a constant is cheap. But it is nice to know the information behind it.

 

[Zeatherann]

Hmm, thank you!