Things That Leak

[TriggerHappy]

Does that destroy the last created unit group or how does it work exacly?

Take a look at this blizzard function.

function ForGroupBJ takes group whichGroup, code callback returns nothing
    // If the user wants the group destroyed, remember that fact and clear
    // the flag, in case it is used again in the callback.
    local boolean wantDestroy = bj_wantDestroyGroup
    set bj_wantDestroyGroup = false

    call ForGroup(whichGroup, callback)

    // If the user wants the group destroyed, do so now.
    if (wantDestroy) then
        call DestroyGroup(whichGroup)
    endif
endfunction

See, if you setbj_wantDestroyGroup to true and call ForGroupBJ then it will destroy the group.

I think it would be best to avoid this way of destroying groups, though.

 

[edo494]

I think it would be best to avoid this way of destroying groups, though.

why?

 

[TriggerHappy]

why?

In some scenarios, I think it could fail.

http://www.wc3c.net/showpost.php?p=1099873&postcount=8

GroupAddGroupdestroys the group before the loop is finished when calling GetUnitsOfTypeIdAll

 

[Maker]

GetUnitsOfTypeIdAll should be avoided, it leaves two local groups unnulled. It is ok to use bj_wantDestroyGroup with Unit group - Pick all units in range matching... even though that leaks also, only less.

 

[Bribe]

If they are using mostly GUI, the handle ID leaks are hardly bad. It's when you use offset -0x100000 that nulling handle ID's becomes immensely important.

 

[sentrywiz]

Floating texts also leak but I understand there is a 100 limit on it so I guess its more of a performance issue rather than a possibility to crash.

Also INIT triggers are called once on start of the map for keeping of vars, creation of stuff and they are never called again (except maybe at end of game in some cases) so this is not a OMG LEAK CLEAN IT UP!

 

[WaterKnight]

Static leaks often do hardly matter.

 

[plumsy460]

What about:
Var = Point with offset

Do you have to define that "point" with another var before doing this?

 

[TriggerHappy]

What about:
Var = Point with offset

Do you have to define that "point" with another var before doing this?

Yes.

 

[Ralle]

You guys should try out this tool. http://www.hiveworkshop.com/forums/site-discussion-97/leaktester-238771/

 

[Troll-Brain]

No, you guys should avoid GUI and learn jass

 

[Daffa]

Ralle, better add that tool to the first page.

 

[Ralle]

Daffy you are right. I should.

 

[TriggerHappy]

Daffy you are right. I should.

or maybe a sticky thread?

 

[Ralle]

You make one, I'll poke at it with my stick!

 

[DelmarVladek]

Wow. I didn't know leaks were this intense, and this diverse.
._.
Good to know this stuff.

 

[plumsy460]

I noticed that when you use a power-up item (tome of power for instance) it leaves a small yellow dot on the ground from the flashy effects. This dot does not vanish.
Is this considered a leak?

I considered changing the item model into a zone indicator. But wouldn't the effect still leak even though you cant see it?

 

[Bribe]

http://www.hiveworkshop.com/forums/spells-569/item-cleanup-1-2-a-201057 <- this resource fixes the leak you mentioned.

 

[plumsy460]

Perfect! Thank you very much!

 

[Kyrbi0]

So why, on the first page, does it mention "Pick all units of unit-type X" as a "blacklisted" function?

 

[Bribe]

It creates a group that leaks a handle. It's a lesser leak, but still something better to avoid.

 

[plumsy460]

Does it leak to use the condition "Unit-Type Comparison"?

 

[IcemanBo]

Does it leak to use the condition "Unit-Type Comparison"?

No leak here.

 

[Neversleeping]

• waypointA1
  • Events
    • Unit - A unit enters waypoint1 <gen>
  • Conditions
    • (Owner of (Triggering unit)) Equal to Player 2 (Blue)
  • Actions
    • (Unit - Order (Triggering unit) to Attack-Move To (Center of waypont2 <gen>))

Quick question. Is the following the correct way of stopping the above leak?

• waypointA1
  • Events
    • Unit - A unit enters waypoint1 <gen>
  • Conditions
    • (Owner of (Triggering unit)) Equal to Player 2 (Blue)
  • Actions
    • Set UnitVar = (Triggering unit)
    • (Unit - Order (UnitVar) to Attack-Move To (Center of waypont2 <gen>)
    • Custom script: call DestroyGroup(udg_UnitVar)

 

[IcemanBo]

Using "TriggeringUnit" does not leak. Storing it into a unit variable makes sense, if you use it more than once in further actions to avoid more function calls.
(TriggeringUnit calls a function each time, so: using variable > function calls)

But back to your leak question, you actually leak a location. Store the point into a variable, and remove the location afterwerds. Read the "Location" chapter in this tutorial.
("Center of waypont2" leaks)

Also, "call DestroyGroup()" is only used for UnitGroups. You don't have any UnitGroup here.

 

[Neversleeping]

I meant to write DestroyUnit or something, but that's seemingly irrelevant as it's the location variable that leaks.
Let me do another attempt...

• waypointA1
  • Events
    • Unit - A unit enters waypoint1 <gen>
  • Conditions
    • (Owner of (Triggering unit)) Equal to Player 2 (Blue)
  • Actions
    • Set TempLocation = (Center of waypont2 <gen>)
    • (Unit - Order (Triggering unit) to Attack-Move To (TempLocation))
    • Custom script: call RemoveLocation(udg_TempLocation)

 

[IcemanBo]

You can't and don't need to destroy "TriggeringUnit". It does not leak. Anyway, now you're doing good about the location leak.

 

[Neversleeping]

Brilliant! thanks.

Oh, one more question. Is it enough to have a single "TempLocation" variable if it's a lot of similiar triggers going on practically at the same time? None of them has any wait-functions, so I presume a single trigger is always finished before another starts?

 

[IcemanBo]

Yes, it is absolutly enough to use one variable for these stuff if it gets cleaned immediatly after usage.

They won't come in conflict, because there are never two functions running the in exact the same time... as you said correctly, they run after each other.

 

[Neversleeping]

Gotcha.
As I started going through the triggers and plug the leaks, yet another thing came to mind. Sorry about all the questions, hope you bear with me! I would totally Rep you if I could at the moment.

If I always use use Set TEMP_Point = (Some Point <gen>) and always make this point the target of the orders, is it really necessary to use RemoveLocation()? I mean, will it not then overwrite the information each time, taking no extra memory space?

 

[IcemanBo]

If you're using a "temp" variable, I would say yes. Because you must pay attention here. You must ensure that you free the memory before you set your variable to a new value.

Set tempLoc = CentreOf_A
...
Set tempLoc = CentreOf_B
call RemoveLocation(udg_tempLoc)
^leak because I didnt free memory before I reused the variable.

For constant unit patrols it would make sense to use location variables which gets initialized once and will never be overwritten again or destroyed.

Init-trigger:
Set RunPoint1 = CentreOf_A
Set Runpoint2 = CentreOf_B

A Unit Enters Region1
Unit - Order TriggeringUnit Move to RunPoint1

A Unit Enters Region2
Unit - Order TriggeringUnit Move to RunPoint2

So in these three triggers you see I set the points once, and they never get touched again. If you can ensure this, then you can do like this.

Contra is that you need to create more variables instead of only one "temp" variable.

If you have more questions you can directly message me to discuss it.

 

[Tirlititi]

Two triggers may run "at the same time" even if there is no wait. It happens when an action done in a trigger triggers the event of another one.
Example :

• Events
  • Player - Some random event
• Actions
  • Player - Display "Step 1" to (All Players)
  • Unit - Order UNIT to move to LOCATION
  • Player - Display "Step 3" to (All Players)

• Events
  • Unit - A unit is given an order targeting a point
• Actions
  • Player - Display "Step 2" to (All Players)

The texts are displayed in the order 1, 2, 3 there (the second trigger runs in the middle of the execution of the first, which resumes once this second trigger's run is over).

This kind of situation is not that much frequent but it can be troublesome (and generate more bugs than a simple memory leak). Be cautious with giving orders, giving/removing items and moving units in particular.

 

[Troll-Brain]

But removing an item (and widget in general) is not something instant, right ?
However killing is instant i think.

I also remember i had an hard time debugging a special case, i tried to ordered an unit (no target, or widget target, or point target) on some order event (no target, or widget target or point target), but the order was not instant and then the check was screwed, but maybe it was just because i paused the unit (can't remember if i paused it or not).

 

[Tirlititi]

I don't remember about the "remove unit" thing. I think the unit is physically removed from the game instantatly (maybe triggering some "death" events or some order events, when they have skills like "defend") and the datas and handle are flushed after a 0 wait. But that's barelly a guess.

For the order, I think it's because it was stuned or paused indeed ^^
Orders given while a unit is stunned are activated only once the stun ends. That I remember.

 

[frettory]

Do regions leak?

 

[IcemanBo]

Just using a region does not leak. But it's still an agent, so you have to remove & null it if you don't need it anymore.

 

[edo494]

that is veeery vague question, elaborate.

Because you can look from multiple angels at this question. Obviously they leak if you dont destroy them when you are done with them, for instance

 

[plumsy460]

So using Center of Region does leak a point?
Unless it is being reused or what?

 

[IcemanBo]

Like Ralle explained in his example, you have to use a point variable and then you can prevent the leak:

Set loc = Centre Of Rect <A>
Unit - Create 1 unit at loc
Custom script: call RemoveLocation(udg_loc)

 

[plumsy460]

I see. If I reuse that location variable "loc" (without changing location), do I still need to remove it to prevent leak?

 

[edo494]

you have to do the custom script, but you can reuse the variable.

This is because the variable is like a finger, and it merely points at the real object(this is called pointer in programming, but it is not begginer-friendly thing)

 

[IcemanBo]

No, sometimes it makes sense to use it like a "constant" point variable. So you never change them, then you don't need to remove them.

If you still wanna refer to the same location later, just let it be. But if you can't ensure that you won't use it in an other trigger (so overwrite the value) then directly remove it after usage.

Basicly for constant spawns/teleport locations it can make sense just to create extra point variables, set them once in init, and then never remove them.

But if you only need it temporary just do it like in the example.

 

[plumsy460]

Very well then. Thanks a lot

 

[Atideva]

• Custom script: set bj_wantDestroyGroup = true
• Group - Pick every unit in (Random 1 units from BlackTornado_Group) and do (Actions)

Is that leak? Cause it use additional function GetRandomSubGroup, which use local group g and do not destoy it.

 

[edo494]

in that case yes, that will leak 1 unit group, because the outer one is destroyed, but the inner one is not

 

[Bribe]

Right, you'd want to use "Set TempGroup = (Random 1 units...)" and then use "Custom script: call DestroyGroup(udg_TempGroup)".

 

[Smiddle]

Do local variables leak?

Say I have a function like this

function CreateCreeps takes arguments returns group
    local group ug
    // some actions
    return ug
endfunction

Will it always leak when called? Since you want to clean the leak every time you call it, it would be convenient to include the cleaning in the script. Is that possible?

 

[WaterKnight]

Not the variable itself, but you will probably reference a real group object with it, therefore increase the reference counter of the object and when the local variable runs out of scope before resetting it, that won't be reverted.

 

[Smiddle]

Not the variable itself, but you will probably reference a real group object with it, therefore increase the reference counter of the object and when the local variable runs out of scope before resetting it, that won't be reverted.

Hm.. so what happens when I use this function in a context? For example,

call CreateCreeps( someArgument )

set udg_awesomeGroup = CreateCreeps( someArgument )
call DestroyGroup( udg_awesomeGroup )

So do these leak? I just want to make sure whether simply calling the group-generating function causes a leak.

 

[edo494]

it still leaks, because the group you returned has not been dereferenced.

This is not the same as object living out of scope. You have to destroy the group after you are done with it(or never, if the group is meant to be for the whole map), but there is another leak. This leak will leak 4 bytes of memory every time you destroy your group and you failed to set all variables that pointed to it to null.

So yes, your example will leak 4 bytes, because blizzard forgot to null local variables when they fall out of scope(you go out of function).

However, this is not something you should be worried about, because the way to prevent this is so stupid noone should bother, ever