Data Leak

[defskull]

If I have 2 variable location, loc1 and loc2 and I do it like this;
set udg_loc1 = udg_loc2, if I want to remove leak, do I have to remove both variable value or just the source (which in this case, loc2 being the source) ?

If a source is destroyed, then udg_loc1 has nothing to hold any longer, meaning that loc1 does not leak, right ?

But if I destroy loc1, will loc2 still leak ?
Because loc1 = loc2, any of them destroy, it will be affected, right ?

So, it is sufficient to only destroy one of them, is it ?

 

[TwoVenomous]

If I have 2 variable location, loc1 and loc2 and I do it like this;
set udg_loc1 = udg_loc2, if I want to remove leak, do I have to remove both variable value or just the source (which in this case, loc2 being the source) ?

If a source is destroyed, then udg_loc1 has nothing to hold any longer, meaning that loc1 does not leak, right ?

But if I destroy loc1, will loc2 still leak ?
Because loc1 = loc2, any of them destroy, it will be affected, right ?

So, it is sufficient to only destroy one of them, is it ?

nope. if you set loc2 = (any regions) and loc1 = loc2.. then you remove loc1, loc1 wouldn't leak but loc2 would still be (any regions) that is leak.. so, you should remove both of them

 

[defskull]

Do you have any solid evidence to back up your statement ?
Like running an experiment ?

 

[mckill2009]

so, you should remove both of them

wrong!, loc1 = loc2

same as:
unitA = templar
unitB = unitA
Kill unitB, does it mean that unitA will not die?...

the loc1 and loc2 points to the same handle, so destroying either of the removes the leak...

 

[defskull]

So, it doesn't care whether you destroy either source or related to it, anything point to the same handle, will get the leak cleaned, right ?

 

[PurgeandFire]

Yes. Remember that you are not destroying the variable, you are simply destroying the object the variable is pointing to. So if loc1 points to Object A and loc2 points to Object A, doing call RemoveLocation(loc1) will remove Object A. All leaks dealt with, no problems.

 

[mckill2009]

yap, the thing is you arenot creating any location for loc1, you just made it equals...

 

[TwoVenomous]

yeah, i'm sorry .. i should've been read this..

http://www.hiveworkshop.com/forums/world-editor-help-zone-98/will-location-leak-if-its-only-stored-variable-222046/

anyway, could we really do this ?

unitA = templar
unitB = unitA
Kill unitB

i just could find kill (triggering unit) and didn't find anything like killing unit in variable

 

[Spartipilo]

But... if LocA holds the LocationHandle and LocB stores the value that's saved in LocA, when you remove LocB, LocA would still have the number of the LocationHandle stored in it.

LocA = 10
LocB = LocA

Remove LocB -->

LocA = 10
LocB = null


... or not?

 

[WaterKnight]

@Spartipilo: Do you refer to integers or locations now?

Integers are primitive. They do not point to another area in memory where the data is stored but rather represent the data themselves. Therefore, they have no Destroy-function and are completely independent.

Locations are handles. The object is somewhere stored by wc3 and you can have multiple and different variables that reference the same memory position of it.

locA = Location(0,0)
locB = locA

Both variables will point to the same object.

RemoveLocation(locB)

The object locB points to will be destroyed. locA and locB still refer to the same memory position and of course, locA will also only find a destroyed object when you ask it for its value.

Now, the object is (almost) gotten rid of but variables also reserve memory. You cannot customize their deallocation process though, that's managed by wc3. Maybe you can imagine hashtable data as variables, there you can actually remove entries via functions but for real wc3 variables, it's automatically done. Global variables are static, they are not destroyed, local variables are deallocated when a function call terminates. What you can do though is to nullify local handle (agent) variables before they die. That is because handle (agent) objects are not fully released until they lose all references that once pointed to them --> all variables, hashtable entries etc. should be off the object. Since you cannot create new global variables and you will likely recycle them, it is negligible for them but local variables are always new ones per function call and Blizzard has blundered it to automatically deregister dying local variables from their former objects --> the object cannot be fully released anymore because there are still references you have no access to anymore.

 

[mckill2009]

A simple trigger would be more than enough to close this thread...

• Untitled Trigger 001
  • Events
    • Time - Elapsed game time is 0.00 seconds
  • Conditions
  • Actions
    • Set L1 = (Center of RegBig <gen>)
    • Set L2 = L1
    • Unit - Create 1 Footman for Player 1 (Red) at L1 facing Default building facing degrees
    • Unit - Create 1 Footman for Player 1 (Red) at L2 facing Default building facing degrees
    • Custom script: call RemoveLocation(udg_L2)
    • Unit - Create 1 Footman for Player 1 (Red) at L1 facing Default building facing degrees

 

[edo494]

waterknight, you have true except:
if you dont null global variable it is still considered a pointer to object(if not "elementary"(thats how I call them)) the handle id wont recycle so it is kind of leaking still
correct me please if Im wrong sice I didnt test it myself

 

[defskull]

For nulling global variable, this has very tiny improvement, compared to nulling a local variable.
Therefore, it's up to you whether you want to null a global variable or not, but nulling a local variable is a MUST.

 

[WaterKnight]

Global variables persist throughout the game and are responsive, so they are not considered as a leak. The object id is not freed before all references are gone, yes, but global variables are usually reused and they are limited.

Well, some other very tiny leak with object variables was reported some years ago, which I cannot confirm nor is it worth the effort.