Does this leak?

[FeelsGoodMan]

Will running a trigger before clearing a leak cause a leak if I use the same location variable?

Example:

• Initiate leak
  • Events
    • Time - Every 1.00 seconds of game time
  • Conditions
  • Actions
    • Set TempLoc = (Position of YourUnit)
    • Trigger - Run Run Leak <gen> (ignoring conditions)
    • Custom script: call RemoveLocation (udg_TempLoc)

• Leak
  • Events
  • Conditions
  • Actions
    • Set TempLoc = (Position of YourUnit)
    • Custom script: call RemoveLocation (udg_TempLoc)

According to logic TempLoc should be overwritten in the trigger that is being run, thus causing a leak. I just want to confirm if that is the case.

 

[BloodSoul]

Yes.

EDIT:
You can also confirm it by adding this to your second trigger's actions, before assigning a new value to tempLoc var.

if udg_TempLoc != null then
    call BJDebugMsg("TempLoc is storing a location object")
endif

 

[FeelsGoodMan]

Ok thanks, it is as I suspected then.

 

[Wrda]

Will running a trigger before clearing a leak cause a leak if I use the same location variable?

Not only running triggers but also triggers that were triggered by another one, like giving an item to a hero and then you have an event on a trigger "unit acquires an item" fires and when it's finished it resumes the first one that caused the latter to fire.
"if udg_TempLocation != null" doesn't check if it is destroyed or not, it simply checks whether you that variable still references it or not.
You might have/haven't destroyed it, it doesn't matter, it still won't be null unless you specifically tell it so. You must null local variables in JASS, but after destroying. Global variables don't need to be nulled (unless you want for some reason).

 

[FeelsGoodMan]

Not only running triggers but also triggers that were triggered by another one, like giving an item to a hero and then you have an event on a trigger "unit acquires an item" fires and when it's finished it resumes the first one that caused the latter to fire.
"if udg_TempLocation != null" doesn't check if it is destroyed or not, it simply checks whether you that variable still references it or not.
You might have/haven't destroyed it, it doesn't matter, it still won't be null unless you specifically tell it so. You must null local variables in JASS, but after destroying. Global variables don't need to be nulled (unless you want for some reason).

Hmm that is good to know. So if I clear the leak before running the trigger (or giving the item as explained in your case) it should work fine then.

 

[Cespie]

Will running a trigger before clearing a leak cause a leak if I use the same location variable?

Example:

• Initiate leak
  • Events
    • Time - Every 1.00 seconds of game time
  • Conditions
  • Actions
    • Set TempLoc = (Position of YourUnit)
    • Trigger - Run Run Leak <gen> (ignoring conditions)
    • Custom script: call RemoveLocation (udg_TempLoc)

• Leak
  • Events
  • Conditions
  • Actions
    • Set TempLoc = (Position of YourUnit)
    • Custom script: call RemoveLocation (udg_TempLoc)

According to logic TempLoc should be overwritten in the trigger that is being run, thus causing a leak. I just want to confirm if that is the case.

You can run this through in your head and easily conclude that it leaks half of the points it generates.

In essence, here's what you're doing:
Generate position 1 and set to TempLoc
Generete position 2 and set to TempLoc (position 1 no longer has a reference and is effectively leaked)
Delete TempLoc (Position 2)
Delete TempLoc (Nothing)
position 1 is never used again, but will remain in the memory.

 

[FeelsGoodMan]

You can run this through in your head and easily conclude that it leaks half of the points it generates.

In essence, here's what you're doing:
Generate position 1 and set to TempLoc
Generete position 2 and set to TempLoc (position 1 no longer has a reference and is effectively leaked)
Delete TempLoc (Position 2)
Delete TempLoc (Nothing)
position 1 is never used again, but will remain in the memory.

I was unsure if that was the actual order of things. As I said, logic implies the order you explained but you never know. I got it confirmed by @Wrda already though.

 

[Cespie]

I was unsure if that was the actual order of things. As I said, logic implies the order you explained but you never know. I got it confirmed by @Wrda already though.

Ah yeah, fair enough.
Yeah, running a trigger will instantly switch the execution to that trigger and then resume to the point in the other trigger where it was called when it's done.
Kinda glad it works that way, synchronization would be a nightmare otherwise.

 

[FeelsGoodMan]

Ah yeah, fair enough.
Yeah, running a trigger will instantly switch the execution to that trigger and then resume to the point in the other trigger where it was called when it's done.
Kinda glad it works that way, synchronization would be a nightmare otherwise.

Yeah true.