Things That Leak

[WaterKnight]

In your snippet it looks like you are using a global variable. They also create a reference and must be reset to undo it. But unlike local variables, global ones never fall out of scope while the map is being played and can therefore be used anew. So the next time you run that code, it will be overwritten. Global variables in wc3 are also static, you do not allocate them ingame, so your possibility of leaking is fairly limited.

Dynamic global variables would be like entries in a hashtable for example. There you are able to always consume new keys and exhaust the memory continuously. Does FlushChildHashtable/FlushParentHashtable properly clean up the references therein btw?

 

[edo494]

the thing is, globals will decrease ref count n variables they point to when you reassign them(set udg_a = A, set udg_a = B will decrement ref counter of A), but the problem is that locals fall out of scope, and the game for some reason never decrements the ref count for the last object stored inside the local variable, so we have to null variables ourselves.

This is however my understanding from the experiments(assigning endlessly to globals did not increase ram usage for me when I tested it).

No idea about Flushes in hashtable

 

[Smiddle]

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

Huh... is the leaking negligible?

 

[edo494]

mostly yes.

Basically this:

function a takes nothing returns AgentType
    local AgentType h = ...
    //some stuff
    return h
endfunction

//to invoke:
AgentType myType = a()

will leak one refcounter object(4 bytes) per function call.

However, the way to prevent is like this:

function a takes nothing returns AgentType
    local AgentType h = ...
    //some stuff
    set GlobalVariableOfSameType = h
    set h = null

    return GlobalVariableOfSomeType
endfunction

//to invoke:
set myLocalVar = a()

This is like 2 additional lines and 1 additional global variable for nothing basically

 

[Wietlol]

What you could do ofcourse is not use local at all and use a global every time.
If you do not use sleep actions, then there should be no problem at all.
You can use TempVariables or even make TempVariableReserved to make sure you won't use the same one over and over again.

 

[edo494]

at that point, you can move back to GUI

 

[Wietlol]

Not really... local variables can be used in GUI too.
It is just that you require JASS to use multiple functions easier and use Natives better.
Also it is faster to write JASS than to click GUI.

 

[WaterKnight]

If it really was 4 bytes per call, that would be grave. It just blocks the id from release (unless you can overflow the counter).

 

[Wietlol]

or you add a handle parameter and give null to the function:

function f takes unit u returns unit
    set u = CreateUnit()
    
    return u
endfunction

set unit_1 = f(null)

 

[sentrywiz]

I want to add my dumb example to things that leak, but its not due to a trigger. Therefor I'm not sure it belongs in this thread, but it belongs somewhere.

If you're gonna use Shockwave, never set its missile speed and terrain deformations to 0.
Its gonna create a massive lag, and then crash after a while.

Always use channel for triggered spells.

 

[Wietlol]

Always use channel for triggered spells.

or attibute bonus or bladestorm or defend/mana shield/etc or any aura and maybe a few more.

 

[edo494]

not leak per se, but its nice piece of information

 

[MantisHair]

Stupid Question?

note that I have no real knowledge of scripting. I have copied some Custom Scripts and used them, but don't really understand the "inner workings" of it so to speak.
If I create a Sound or a Special Effect, then destroy it later, do I need to destroy the location?
Like so:

• LegionCHECK
  • Events
  • Conditions
  • Actions
    • Special Effect - Create a special effect attached to the overhead of Legion_Check using Abilities\Spells\Items\AIsp\SpeedTarget.mdl
    • Set Legion_Sign = (Last created special effect)
    • Set Legion_Holder = Legion_Check
    • Set Legion_Check = No unit
    • Trigger - Turn on Legion RECOV <gen>
    • Trigger - Turn off (This trigger)

Second trigger:

• Legion REMOVE
  • Events
    • Unit - A unit Loses an item
  • Conditions
  • Actions
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • ((Triggering unit) is A Hero) Equal to True
        • Or - Any (Conditions) are true
          • Conditions
            • (Item-type of (Item being manipulated)) Equal to Legion Mail
            • (Item-type of (Item being manipulated)) Equal to Legion Sword
            • (Item-type of (Item being manipulated)) Equal to Legion Cloak
      • Then - Actions
        • Special Effect - Destroy Legion_Sign
        • Set Legion_Holder = No unit
        • Trigger - Turn off Legion RECOV <gen>
        • Trigger - Turn on Legion <gen>
        • Trigger - Turn on LegionCHECK <gen>
      • Else - Actions
        • Do nothing

Should I add "Remove Location" Custom Scripts?

 

[Gismo359]

Well, RemoveLocation removes a location(point), and since you arent using any, you shouldnt (and cant) remove a location(point).

 

[MantisHair]

Duh. I feel like a... Peon.

I should have figured that out myself. Units are "things" (so are destructibles) and not "places".
By the way, do regions pre-placed on the map leak?
(ex: from my current map, a region "Floorpad 1", it makes a door doodad open)
I don't see why they should, regions aren't points.
Also, should I RemoveLocation for triggers that use the center of a pre-placed region?
Like "Unit - Create 1 Footman for Player 1 (Red) at (Center of SpawnFootman)"

 

[edo494]

Regions can leak too, you dont need point(location) to leak, but the preplaced regions do not leak per se. But if you do something like "Center of (Some preplaced region)", that is effectivelly location leak

 

[MantisHair]

Thanks.

Thank you, made things more clear.
If I have a point array, how do I call Remove Location for each index?
Or do I just put the variable name into the script and ignore the index numbers and it will do all locations for that point array?

The point array is like this:

• Set LeapTemps[(Integer A)] = (LeapTarget offset by LeapStep[(Integer A)] towards LeapMoveAngle degrees)

I have 10 or so temp locations per each cast of the spell this is for, so removing all of them is important.

 

[edo494]

you just do:

call RemoveLocation(udg_myLocationArray[udg_myIndex])

 

[MantisHair]

Thanks again.

Does that work in an Integer Loop setup?
Like call RemoveLocation(udg_Array[udg_Integer A])

 

[MantisHair]

Apparently not.
I tried to save the map, and when it got to "Validating map script" it returned an error for using "call RemoveLocation(udg_LeapTemps[Integer B])" with a "For every integer B, do *an action*.

 

[Bribe]

Use "bj_forLoopBIndex" not "Integer B" when you use custom script.

 

[Light]

quick question,
if you use a variable multiple times before clearing it, does it leak?

 

[Pinzu]

quick question,
if you use a variable multiple times before clearing it, does it leak?

A leak is a variable stored in the memory which you can no longer access. How many times you use something has no baring whether it leaks or not.

for example local unit u = GetTriggerUnit(), we have now created a variable containing a unit, but once the function is done this data is still stored but not retrievable.

 

[edo494]

not true entirely.

Variables are only pointers, they dont store anything physically, they just point to your memory, + GetTriggerUnit does not allocate any memory, so all you really leak is handleid if you dont null u.

Light, yes:

local location l = Location(0, 0)
set l = Location(0, 1)
call RemoveLocation(l)
set l = null

will leak 1 location, because the second call to location makes l point to somewhere else, but the memory itself is still in there(allocated), so it cant be freed = memory leak

 

[Light]

good to know!

might have misunderstood a tiny bit, but what if you don't change the variable but you still use it for multiple actions?

 

[edo494]

you can use it as many times as you want, but if you want to assign it to new value, you have to clean it before assigning

 

[Light]

i see, thanks for clearing that up.

 

[HandsOfficial]

why does it leak? it has to be some kind of bug in the editor itself yes? wtf?

 

[Bribe]

Which leak are you referring to? The handle ID leak described above?

 

[Hotwer]

Isn't it possible to create like a "Garbage Collector" to Destroy leaked Locations?

It really sounds totally odd that a position that wans't even stored in a variable to leak (I know it actually uses it code-behind, but just looks retarded to me that Blizzard didn't did that).

 

[Dr Super Good]

Isn't it possible to create like a "Garbage Collector" to Destroy leaked Locations?

It really sounds totally odd that a position that wans't even stored in a variable to leak (I know it actually uses it code-behind, but just looks retarded to me that Blizzard didn't did that).

They did this for StarCraft II. Seeing how WC3 even has a handle table with reference count, either it lacking was an oversight or it does exist but does not work.

 

[Hotwer]

They did this for StarCraft II. Seeing how WC3 even has a handle table with reference count, either it lacking was an oversight or it does exist but does not work.

Is it possible to create a custom one, then?

 

[Dr Super Good]

Is it possible to create a custom one, then?

Yes one could use wrapper functions to create such a system. However these will come at a heavy performance cost. It is far easier/efficient to use the destructor functions when appropriate.

A third party optimizing JASS re-compiler might be able to detect some leaks and automatically resolve some types of them. However it should always generate a warning and even throw an error if it is certain there is a leak that cannot be resolved.

For Blizzard I would not imagine it being that hard, possibly for one person a day of work or two depending on the code complexity as well as giving basic testing. Maybe more work needed to fix some oversights down the line. It would deprecate the destructor natives.

 

[Hotwer]

Yes one could use wrapper functions to create such a system. However these will come at a heavy performance cost. It is far easier/efficient to use the destructor functions when appropriate.

A third party optimizing JASS re-compiler might be able to detect some leaks and automatically resolve some types of them. However it should always generate a warning and even throw an error if it is certain there is a leak that cannot be resolved.

For Blizzard I would not imagine it being that hard, possibly for one person a day of work or two depending on the code complexity as well as giving basic testing. Maybe more work needed to fix some oversights down the line. It would deprecate the destructor natives.

No, I mean like a real Garbage collector, that from time to time, clears up memory space.

 

[Dr Super Good]

No, I mean like a real Garbage collector, that from time to time, clears up memory space.

I doubt memory fragmentation is much of a problem in WC3. For all we know WC3 might already periodically perform a garbage collection cycle, if its allocation structure permits.

People would find it much more useful to have leak prone objects auto destruct.

 

[Atirak]

If (All Players) do not cause leaks...

How 'bout (All Players Matching Condition) or (All Players of Control)? Do they cause leak?

 

[TriggerHappy]

If (All Players) do not cause leaks...

How 'bout (All Players Matching Condition) or (All Players of Control)? Do they cause leak?

No unless the matching condition creates a new handle.

 

[Jampion]

Are you sure @TriggerHappy ? In both functions local force f = CreateForce() is used.
I thought you have to destroy the forces, so they don't leak.
I rarely use forces, so please correct me, if I am wrong.

Spoiler

function GetPlayersByMapControl takes mapcontrol whichControl returns force
    local force f = CreateForce()
    local integer playerIndex
    local player  indexPlayer

    set playerIndex = 0
    loop
        set indexPlayer = Player(playerIndex)
        if GetPlayerController(indexPlayer) == whichControl then
            call ForceAddPlayer(f, indexPlayer)
        endif

        set playerIndex = playerIndex + 1
        exitwhen playerIndex == bj_MAX_PLAYER_SLOTS
    endloop

    return f
endfunction

Spoiler

function GetPlayersMatching takes boolexpr filter returns force
    local force f = CreateForce()
    call ForceEnumPlayers(f, filter)
    call DestroyBoolExpr(filter)
    return f
endfunction

 

[TriggerHappy]

@Jampion Yeah it seems you're right

 

[Dr Super Good]

Be aware that due to the local declared local handle variable reference counter leak on return bugs those functions leak a handle index, even if the force associated with it is destroyed.

 

[Arohk]

how it feels when i try to fix the leaks in my map right now while i am reading through this .

Did the guys from Blizzard back then not think about it or did they not care because they thought it doesnt matter?

 

[Dr Super Good]

Did the guys from Blizzard back then not think about it or did they not care because they thought it doesnt matter?

JASS2 was never intended to be used in the ways people have ended up using it. One can safely assume the "local declared local handle variable reference counter leak on return bug" was an oversight/programming error.

 

[Arohk]

JASS2 was never intended to be used in the ways people have ended up using it. One can safely assume the "local declared local handle variable reference counter leak on return bug" was an oversight/programming error.

yeah, i guess they did not expect people to create such complex maps or games with it, for normal melee maps it realy doesnt matter at all.

 

[Bribe]

Guess what, the ones who made campaing maps (the only guys who ever worked with JASS2, obviously) had no idea about programming. They are game designers. They had no idea about inneries at all. So nobody ever fixed those issues. What u should think, is rather "why the fuck they didn't fixed it with later patches", which will reveal ugly truth for you.

The fact we even GET updates to this 16 year old game is mind blowing. Figuring out how to work with this old engine is what keeps it an ever-ongoing pleasure/struggle.

 

[MyPad]

Guess what, the ones who made campaing maps (the only guys who ever worked with JASS2, obviously) had no idea about programming. They are game designers. They had no idea about inneries at all. So nobody ever fixed those issues. What u should think, is rather "why the fuck they didn't fixed it with later patches", which will reveal ugly truth for you.

Welcome back!

 

[Bribe]

????? Titan Quest. Game with much lower hype was updated and HEAVILY. Stop this retarded "16 yo" bullshit, it have nothing to do with the facts they did nothing yet, except for breaking tons of stuff for past 1.5 years.

Lol, the support for this game is better than what they've done with Hearthstone. Calm down kiddo.

 

[Bribe]

>>halved official servers online
>>support
w/e

Considering how much money they extort from their HS players and how anything they invest into WarCraft 3 is a literal charity, yes, the support for WarCraft 3 is much better than HS. Do they have more manpower on maintaining HS? Naturally. It keeps the cash cow alive. But they don't care about existing cards: just print more. The inflation (aka Power Creep) has killed the game, which was an intentional design choice to run players into the ground who don't pour money into the game.

Meanwhile, I spent 40 bucks on WarCraft 3 16 years ago, another 30 15 years ago, and I've never had to pay another dime since. The fact they choose to maintain this game instead of dump it is literally a VERY GOOD THING.

 

[KILLCIDE]

@Arohk you must be doing something wrong then. Fixing leaks is child's play.

 

[Kaijyuu]

Ain't the user's fault if the program does its job poorly. There's a reason every scripting language and most high level languages have garbage collection; it's not something the programmer really ought to worry about.

Wc3's excuse is being a really old game. Even considering that, it's still a bit poorly coded (see the laughable way the implemented localizations). I don't blame new coders at all for having leaks; it's an arcane and unintuitive process to remove them, easy though it may be once you know how.

 

[blackrat5521]

• Leak
  • Events
  • Conditions
  • Actions
    • Unit - Move (Triggering unit) instantly to ((Position of (Triggering unit)) offset by 100.00 towards 180.00 degrees)
    • -------- Leaks Twice! --------
    • -------- --------
    • Set TempPoint = (Position of (Triggering unit))
    • Unit - Move (Triggering unit) instantly to (TempPoint offset by 100.00 towards 180.00 degrees)
    • Custom script: call RemoveLocation(udg_TempPoint)
    • -------- Still leaks a location --------
    • -------- --------
    • Set TempPoint = (Position of (Triggering unit))
    • Set TempPoint2 = (TempPoint offset by 100.00 towards 180.00 degrees)
    • Unit - Move (Triggering unit) instantly to TempPoint2
    • Custom script: call RemoveLocation(udg_TempPoint)
    • Custom script: call RemoveLocation(udg_TempPoint2)
    • -------- Finnaly no leaks! --------

PolarProjection(Point with polar offset) also creates a location, meaning that it has to be set to a variable and removed.

Does this include something when you create it with default building facing, meaning you only have to worry about this if it is not in default?

• Set Point = (Random point in Hives <gen>)
• Unit - Create 1 Hive (H) for Player 12 (Brown) at Point facing Default building facing degrees
• Custom script: call RemoveLocation(udg_Point)