[JASS] Does this leak?

[blah900]

local trigger ArrowBarrage = CreateTrigger()
local triggeraction ArrowBarrageActionsA = TriggerAddAction(ArrowBarrage, function ArrowBarrageActions)
local unit u
local location l = GetSpellTargetLoc()
set u = CreateUnit(GetOwningPlayer(GetTriggerUnit()), 'n003',GetUnitX(GetTriggerUnit()), GetUnitY(GetTriggerUnit()), 0)
call IssuePointOrderLoc(u,"clusterrockets", l)
call UnitApplyTimedLife(u,'BTLF',8)
call SaveUnitHandle(abilHash, StringHash("Unit1"), GetHandleId(GetTriggerUnit()), u)

set u = CreateUnit(GetOwningPlayer(GetTriggerUnit()), 'n003',GetUnitX(GetTriggerUnit()), GetUnitY(GetTriggerUnit()), 0)
call IssuePointOrderLoc(u,"clusterrockets", l)
call UnitApplyTimedLife(u,'BTLF',8)
call SaveUnitHandle(abilHash, StringHash("Unit2"), GetHandleId(GetTriggerUnit()), u)


call TriggerRegisterUnitEvent(ArrowBarrage,GetTriggerUnit(), EVENT_UNIT_SPELL_ENDCAST)

call TriggerSleepAction(8)

call FlushChildHashtable(abilHash,GetHandleId(GetTriggerUnit()))
call TriggerRemoveAction(ArrowBarrage, ArrowBarrageActionsA)
call DestroyTrigger(ArrowBarrage)    
set ArrowBarrage = null
set ArrowBarrageActionsA= null
set u = null
call RemoveLocation(l)
set l = null

 

[PurgeandFire]

No leaks.

EDIT: Seems like I didn't look at it thoroughly enough. Berb is right.

 

[Berb]

Actually, there is something.

You save your unit handles to location StringHash("Unit1"), GetHandleId(GetTriggerUnit()) but you flush the child hash-table at index GetHandleId(GetTriggerUnit()), which means there will still be values associated with StringHash("Unit1"), GetHandleId(GetTriggerUnit()). Since they are unit handles, I'd think this may be problematic when the handle ID needs to be recycled.

Also, what is this?

local triggeraction ArrowBarrageActionsA = TriggerAddAction(ArrowBarrage, function ArrowBarrageActions)

 

[blah900]

Actually, there is something.

You save your unit handles to location StringHash("Unit1"), GetHandleId(GetTriggerUnit()) but you flush the child hash-table at index GetHandleId(GetTriggerUnit()), which means there will still be values associated with StringHash("Unit1"), GetHandleId(GetTriggerUnit()). Since they are unit handles, I'd think this may be problematic when the handle ID needs to be recycled.

Also, what is this?

local triggeraction ArrowBarrageActionsA = TriggerAddAction(ArrowBarrage, function ArrowBarrageActions)

Doesn't the flushing of child hashtable get rid of all the values associated with that child including the StringHash?

As for the local triggeraction arrowBarrageActonsA, that's some other function that I made that doesn't leak.

 

[Berb]

Doesn't the flushing of child hashtable get rid of all the values associated with that child including the StringHash?

You are not flushing the child hashtable at StringHash("Unit1") you are flushing the child hashtable at GetHandleId(GetTriggerUnit()). You can't just mix and match the indexes. They have to be in the correct order.

The native FlushChildHashtable takes an integer index of the secondary table that you want to be cleared. Think of it as a 2-dimensional array. If you have [2][3] and you want to clear the hash-table at [2] it would clear all values associated with [2], meaning [2][3]. If there were also a 2[6], or 2[5], those would also be included and be flushed Just to be perfectly clear, if you had values saved at [2][3], [2][5]. 2[7], and [3][9], using the following line of code: call FlushChildHashtable(2) would result in the hash-table only having a value at [3][9], as it is not included in the child hash-table at index "2".

If you want to remove an individual value, then you can do RemoveSavedInteger as an example which will allow you (using the previous example) to remove a specific data entry at [2][3]. There is also a native FlushParentHashtable which takes a hash-table and clears all values associated with it.

As for the local triggeraction arrowBarrageActonsA, that's some other function that I made that doesn't leak.

I realized shortly after writing that you also remove it after your TriggerSleepAction.

 

[blah900]

So, if I said
SaveInteger(SomeHash,1,2, SomeInteger)
SaveInteger(SomeHash,1,3, SomeInteger)

Would the 1 be the child hashtable and 2 and 3 be the actual place of stored values?
or
would the 2 and 3 be the child hashtables and 1 be the place of stored value?

I guess this is what I was confused on the most.

 

[Berb]

The parent hash-table is the first index. The child hash-table is the second index. The actual value is located in the child hash-table. In order to clear a child hash-table, you need the parent hash-table's index so that it can clear the child hash-table associated with that index.

In your situation, you've got a parent hash-table at index "1" and a child hash-table which has values at index "2" and "3". If you are to clear the "child" hash-table you would give it index "1", which would in turn clear values at [1][2] and [1][3].

 

[blah900]

Ooh, I see thank you very much!