Things That Leak

[loktar]

I see, interesting. Is it possible JASS strings are null-terminated? So nullAsString actually returns something like "\0" ? Dunno, don't know much about the internal workings of these things, though I have experience with C++.

 

[IcemanBo]

Not sure, but yeh I think they're null terminated, at least it's most likely they're also normal c++ strings.

That nullAsString() didn't work for concatenation as first parameter with +operator...: param1 + param2 ... makes me think it doesn't return any valid string, also not "\0". So tying to call the c++ concat from jass vm will not work correctly.
And that nullAsString() is accepted as second param is maybe only because of extra vm checks, before calling the c++ concat.
But... hey, it's just my theory, maybe it's simply wrong, too.

 

[loktar]

hehe, well guessing is the best we can do without any official documentation xD

 

[Mightylink]

Thank you for creating this thread, I added it to my notes of things to do whenever I create a trigger, you're breathtaking!

 

[Map Designer]

does string variable leak when used multiple times?

Also, strings technically leak.
-Strings, but the reference is only created once. The same string won't leak twice, unlike most leaks.

but if doesnt leak twice then it is not leak right? because each variable will take memory once anyway; the problem with leaks is that they take more and more memory if not destroyed/cleared.

 

[IcemanBo]

This thread covers very much information: [Documentation] String Type

What is meant is that a when a string is used for the first time, for example "Hello", then this will take up memory, and it gets written into a string table. This entry from string table will never be removed.
But also, from then on, when ever you use "Hello" again, it will use this same entry from the string table.

But what might be important is that it's talking about JASS, not Lua.

 

[loktar]

If it happens whatever you do, and you can't remove it from the string table, then I wouldn't really call it a leak.

 

[Map Designer]

If it happens whatever you do, and you can't remove it from the string table, then I wouldn't really call it a leak.

why? if something uses unwanted memory its a leak, whether this leak can be removed or not is another story.


@IcemanBo Paladin and then pal or paladin01 will use 3 different locations in string table right?

 

[loktar]

Well, it seems to be by design. The string is stored permanently for later reuse. Whether it's a good design is up for debate and depends on the use-case, but I wouldn't say it's a leak. A leak is when memory becomes unreadable and unwriteable unless you do garbage collection, IMO. In this case, the memory is still accessible and the data stored is still useful as long as you use the same string again.

 

[IcemanBo]

@IcemanBo Paladin and then pal or paladin01 will use 3 different locations in string table right?

Yes and it's explained in the linked thread.

 

[Map Designer]

I have 2 Qs

First, the Custom script: set bj_wantDestroyGroup = true is global variable right? so I only need to use it in map initialization and not have to use it in each trigger in my map right?

2nd
it seems to me that Custom script: call RemoveLocation(udg_loc) and the Custom script: call DestroyGroup(udg_GroupVar)
are better used just before setting up the group so that the old one is deleted. no?

 

[loktar]

AFAIK there's no reason to use that variable at all (bj_wantDestroyGroup). It's something that's used in BJ functions.

RemoveLocation/DestroyGroup should be used on any location/group that isn't used anymore. So yes, definitely do it before reassigning the variable.

 

[Map Designer]

AFAIK there's no reason to use that variable at all (bj_wantDestroyGroup). It's something that's used in BJ functions.

RemoveLocation/DestroyGroup should be used on any location/group that isn't used anymore. So yes, definitely do it before reassigning the variable.

in most practices I saw it done the other way around. everything is removed at the end of trigger that used it, and not at the beginning of trigger that will use it.

 

[loktar]

Well yeah, what I mean is, if you have a unit group variable which is assigned a unit group, you should destroy that unit group before assigning a different unit group to that variable.
Basically it should be destroyed once its not used anymore, regardless of what you do with the variable afterward.
Usually this is at the end of a trigger/function, but in some cases it may be at different places.

 

[IcemanBo]

bj_wantDestroyGroup is a global and will be reset to false in the GUI/BJ functions. So it would not be enough to set it to true only once.
The other one is a design question, but most common practice is to clear things when their job is done, instead of requiring others to clean things before they start.

 

[Map Designer]

bj_wantDestroyGroup is a global and will be reset to false in the GUI/BJ functions. So it would not be enough to set it to true only once.
The other one is a design question, but most common practice is to clear things when their job is done, instead of requiring others to clean things before they start.

hmmm,

I was thinking there was a chance that the same group might be used by another trigger, but maybe you are right.

 

[Map Designer]

bj_wantDestroyGroup is a global and will be reset to false in the GUI/BJ functions. So it would not be enough to set it to true only once.

at least it will be enough once in each trigger right? so If I have a loop that will use the same location variable 100 times, it is enough to use the custom script once and it will not leak? I mean Custom script: set bj_wantDestroyGroup = true

Edit: wait I don't see in OP equivalent of WantDestroyLocation = true; such thing doesnt exist?

 

[loktar]

You should not rely on any bj_wantDestroyX (not sure if any exist beside the one for Group). It's best to just `call DestroyGroup(group)` manually.

 

[TheFireMage]

Will it leak if I use a region variable?

 

[Map Designer]

The region should be destroyed unless it's one that you've created with the editor.

This is fine:

• Destructible - Pick every destructible in MyRegion <gen> and do (Destructible - Kill (Picked destructible))

This leaks a region:

• Destructible - Pick every destructible in (Region(0.00, 0.00, 0.00, 0.00)) and do (Destructible - Kill (Picked destructible))

Can be fixed like this:

• Custom script: set udg_TempRegion = Rect(0, 0, 0, 0)
• Destructible - Pick every destructible in TempRegion and do (Destructible - Kill (Picked destructible))
• Custom script: call RemoveRect(udg_TempRegion)
• Set TempRegion = No region

this

 

[TheFireMage]

Thanks

 

[Wrda]

No need to set TempRegion to null (No region) unless it's a local variable.

 

[proudmer22]

Just how much "leaks" is enough to slow down the game? I did a revision in my scripts, removing all "Center of region" functions. But it turns cutscene-making proccess into a chore(units get moved to the Center of region, I order units to go to the center of region ects..). I'm wondering if I should remove leaks in cutscenes..
Is there an 'approximate" number of "Center of region" leaks that should happen before game starts lagging because of it?

 

[IcemanBo]

Single leaks are mostly not important, if something only fires once. Loops/periodic stuff is important.
If that source is still correct, that a location leaks 0.361 KB, then it takes for example 10'000 locations to occupy 1/3 GB. It might be handled, but it's already a concern. Warcraft takes RAM itself, all your other objects, terrain etc needs RAM, too... and I think it's capped to 2 or 3 GB in total.

 

[proudmer22]

Good. Thanks.

Single leaks are mostly not important, if something only fires once. Loops/periodic stuff is important.
If that source is still correct, that a location leaks 0.361 KB, then it takes for example 10'000 locations to occupy 1/3 GB. It might be handled, but it's already a concern. Warcraft takes RAM itself, all your other objects, terrain etc needs RAM, too... and I think it's capped to 2 or 3 GB in total.

Just wondering. Is this something that can't be fixed by Blizzard over these years? The solutions seems as simple as adding a one line of code.

 

[Kyrbi0]

Seems like it... Rarely is.

 

[Duckfarter]

Will "set bj_wantDestroyGroup = true" clean the leak when setting this unit variable?

• Custom script: set bj_wantDestroyGroup = true
• Set VariableSet Nearby_Target_Kenneth = (Random unit from (Units within 3200.00 of Loc[7] matching (((Unit-type of (Matching unit)) Equal to Scared Pig) and ((((Matching unit) is alive) Equal to True) and ((((Matching unit) is invulnerable) Equal to False)

 

[Itachi2020]

Does this leak? If so, what's the script to remove? (Not the location - the destructible group)

• Destructible - Pick every destructible within 500.00 of TempPoints[1] and do (Actions)
  • Loop - Actions
    • Destructible - Remove (Picked destructible)

 

[Wrda]

The one above me doesn't.

Will "set bj_wantDestroyGroup = true" clean the leak when setting this unit variable?

• Custom script: set bj_wantDestroyGroup = true
• Set VariableSet Nearby_Target_Kenneth = (Random unit from (Units within 3200.00 of Loc[7] matching (((Unit-type of (Matching unit)) Equal to Scared Pig) and ((((Matching unit) is alive) Equal to True) and ((((Matching unit) is invulnerable) Equal to False)

Yes.

 

[Map Designer]

Just to double check: using max of region and min of region should not leak because we are using real number and not point right?

something like this

• Set RealNumber = ((Max Y of Region) - (Min Y of Region))

 

[AGD]

right?

Yes

 

[Map Designer]

1. Does restarting the map remove leaks?
2. does quitting the map remove leak?
3. does shutting down WC3 remove leaks?

Edit: btw, I learned how to refer to integer B of the for loop using custom script. someone might find it useful to remove point array leaks using for loops.

• Custom script: call RemoveLocation(udg_Loc_SpawnPoint[GetForLoopIndexB()])

Merged:
Does Pause/unpause all units leak?

 

[Map Designer]

I have 2 questions.

First, is the trigger below fine:

• AutoCastEnhanced
  • Events
    • Unit - A unit Begins casting an ability
  • Conditions
  • Actions
    • Unit Group - Pick every unit in (Units currently selected by Player 1 (Red)) and do (Actions)
      • Loop - Actions
        • Unit - Order (Picked unit) to Undead Death Knight - Animate Dead
    • Custom script: call DestroyGroup(GetLastCreatedGroup())

Second question: is there a way to know the trigger above is fine without asking in this thread?

 

[GIMLI_2]

I have 2 questions.

First, is the trigger below fine:

• AutoCastEnhanced
  • Events
    • Unit - A unit Begins casting an ability
  • Conditions
  • Actions
    • Unit Group - Pick every unit in (Units currently selected by Player 1 (Red)) and do (Actions)
      • Loop - Actions
        • Unit - Order (Picked unit) to Undead Death Knight - Animate Dead
    • Custom script: call DestroyGroup(GetLastCreatedGroup())

Second question: is there a way to know the trigger above is fine without asking in this thread?

Take a look at common.j and blizzard.j
-> JASS Manual: API Browser - Functions in common.j
-> JASS Manual: API Browser - Functions in Blizzard.j
there you can look what these functions actually do. In your example, it would be GetLastCreatedGroup(), which does the following:

function GetLastCreatedGroup takes nothing returns group
    set bj_groupLastCreatedDest = CreateGroup()
    call ForGroup(bj_lastCreatedGroup, function GetLastCreatedGroupEnum)
    return bj_groupLastCreatedDest
endfunction

function GetLastCreatedGroupEnum takes nothing returns nothing
    call GroupAddUnit(bj_groupLastCreatedDest, GetEnumUnit())
endfunction

It's a bit confusing for me, but it looks like the function creates a new group and basically copies all units of your current ForGroup into the new one and returns it, correct me if i'm wrong.

So it does return a group with the same units, but it's a different instance. Your code line basically does nothing then (it creates a new group and instantly destroys it)

call DestroyGroup(GetLastCreatedGroup()) //this one

 

[Map Designer]

Pause- all units
unpause- all units


??

 

[RAFAEL GRACIANO]

hello , ppl. I have a question and couldn't find a proper answer (page 1 didn't make it clear because of the editions).
Does a created variable with Polar Offset leak, just like the example below?

• Events
  • A unit dies
• Conditions
  • (Triggering Unit) is a Hero equal to true
• Actions
  • Set TempLoc = Position of Triggering Unit
  • Set TempLoc2 = (TempLoc offset by 256.00 towards 90.00 degrees)
  • Custom script: call RemoveLocation(udg_TempLoc)
  • Custom script: call RemoveLocation(udg_TempLoc2)

 

[AGD]

@RAFAEL GRACIANO Yes, because it creates a new location.

 

[Map Designer]

@RAFAEL GRACIANO Yes, because it creates a new location.

but the trigger example he gave seem leakless to me since he cleared both variables properly.

 

[RAFAEL GRACIANO]

hello , ppl. I have a question and couldn't find a proper answer (page 1 didn't make it clear because of the editions).
Does a created variable with Polar Offset leak, just like the example below?

Spoiler

• Events
  • A unit dies
• Conditions
  • (Triggering Unit) is a Hero equal to true
• Actions
  • Set TempLoc = Position of Triggering Unit
  • Set TempLoc2 = (TempLoc offset by 256.00 towards 90.00 degrees)
  • Custom script: call RemoveLocation(udg_TempLoc)
  • Custom script: call RemoveLocation(udg_TempLoc2)

but the trigger example he gave seem leakless to me since he cleared both variables properly.

I was wondering if setting a polar with degree offset is a leak that should be declared as a real variable, I guess. And therefore, it makes the TempLoc2 insufficient

 

[GIMLI_2]

hello , ppl. I have a question and couldn't find a proper answer (page 1 didn't make it clear because of the editions).
Does a created variable with Polar Offset leak, just like the example below?

• Events
  • A unit dies
• Conditions
  • (Triggering Unit) is a Hero equal to true
• Actions
  • Set TempLoc = Position of Triggering Unit
  • Set TempLoc2 = (TempLoc offset by 256.00 towards 90.00 degrees)
  • Custom script: call RemoveLocation(udg_TempLoc)
  • Custom script: call RemoveLocation(udg_TempLoc2)

You cleared all leaks properly in this example.

 

[Map Designer]

I was wondering if setting a polar with degree offset is a leak that should be declared as a real variable, I guess. And therefore, it makes the TempLoc2 insufficient

Real numbers do not leak. as far as I know, the only two things that can leak are locations (points) and groups (both unit groups or player groups as explained in OP).

Just to double check: using max of region and min of region should not leak because we are using real number and not point right?

something like this

• Set RealNumber = ((Max Y of Region) - (Min Y of Region))

Yes

 

[Map Designer]

(Count structures controlled by Player 12 (Brown) (Exclude incomplete structures)) Equal to 0
This does not leak as far as I can tell.

Hello,
so I have converted these kinds of conditions to JASS to check if any group is created. Seems like the last condition does leak, but what about the third condition?
Here is the GUI code followed by the converted code.

• Melee Initialization
  • Events
    • Map initialization
  • Conditions
    • (Count structures controlled by Player 1 (Red) (Include incomplete structures)) Equal to 0
    • (Count non-structure units controlled by Player 1 (Red) (Exclude incomplete units)) Equal to 1
    • (Number of living Footman units owned by Player 1 (Red)) Equal to 2
    • (Number of units in (Units owned by Player 1 (Red))) Equal to 3
  • Actions

function Trig_Melee_Initialization_Copy_Conditions takes nothing returns boolean
    if ( not ( GetPlayerStructureCount(Player(0), true) == 0 ) ) then
        return false
    endif
    if ( not ( GetPlayerUnitCount(Player(0), false) == 1 ) ) then
        return false
    endif
    if ( not ( CountLivingPlayerUnitsOfTypeId('hfoo', Player(0)) == 2 ) ) then
        return false
    endif
    if ( not ( CountUnitsInGroup(GetUnitsOfPlayerAll(Player(0))) == 3 ) ) then
        return false
    endif
    return true
endfunction

function Trig_Melee_Initialization_Copy_Actions takes nothing returns nothing
endfunction

//===========================================================================
function InitTrig_Melee_Initialization_Copy takes nothing returns nothing
    set gg_trg_Melee_Initialization_Copy = CreateTrigger(  )
    call TriggerAddCondition( gg_trg_Melee_Initialization_Copy, Condition( function Trig_Melee_Initialization_Copy_Conditions ) )
    call TriggerAddAction( gg_trg_Melee_Initialization_Copy, function Trig_Melee_Initialization_Copy_Actions )
endfunction

 

[pr114]

You can look this up by looking into the following documents:
common.j
blizzard.j

Any function that creates a game engine object with handle will definitely leak.

GetPlayerStructureCount > can be found in common.j, doesn't appear to create an object
CountLivingPlayerUnitsOfTypeId > can be found in blizzard.j, creates a group, destroy it, but doesn't nil the local group variable. So in JASS, this function will create an unpreventable handle leak. In lua it doesn't leak.
CountUnitsInGroup> can be found in blizzard.j, doesn't create an object or unremovable handle reference

Aside from what can be seen in above documents, many functions run in the engine internally, and it is unknown what they do exactly. For instance, it was tested that CreateUnit creates a memory leak even if everything is properly removed. This is tested by running the function many times, and see the game memory usage permanently go up. I'm not sure for which different functions this has been tested and which haven't, but I think I've read here that most functions do not have such memory leak.

 

[Map Designer]

You can look this up by looking into the following documents:
common.j
blizzard.j

Any function that creates a game engine object with handle will definitely leak.

GetPlayerStructureCount > can be found in common.j, doesn't appear to create an object
CountLivingPlayerUnitsOfTypeId > can be found in blizzard.j, creates a group, destroy it, but doesn't nil the local group variable. So in JASS, this function will create an unpreventable handle leak. In lua it doesn't leak.
CountUnitsInGroup> can be found in blizzard.j, doesn't create an object or unremovable handle reference

Aside from what can be seen in above documents, many functions run in the engine internally, and it is unknown what they do exactly. For instance, it was tested that CreateUnit creates a memory leak even if everything is properly removed. This is tested by running the function many times, and see the game memory usage permanently go up. I'm not sure for which different functions this has been tested and which haven't, but I think I've read here that most functions do not have such memory leak.

All I can see in common.j is this, which doesnt tell me if it creates group or not

constant native GetPlayerTypedUnitCount takes player whichPlayer, string unitName, boolean includeIncomplete, boolean includeUpgrades returns integer
constant native GetPlayerStructureCount takes player whichPlayer, boolean includeIncomplete returns integer

 

[pr114]

The functions in common.j that create an object generally have 'Create' in the name, and they always return an object like group, timer, etc.
This function returns integer, so it's probably safe.

 

[Dr Super Good]

so I have converted these kinds of conditions to JASS to check if any group is created. Seems like the last condition does leak, but what about the third condition?

Leaks a handle ID.

function CountLivingPlayerUnitsOfTypeId takes integer unitId,player whichPlayer returns integer
    local group g
    local integer matchedCount
    set g = CreateGroup()
    set bj_livingPlayerUnitsTypeId = unitId
    call GroupEnumUnitsOfPlayer(g, whichPlayer, filterLivingPlayerUnitsOfTypeId)
    set matchedCount = CountUnitsInGroup(g)
    call DestroyGroup(g)
    return matchedCount
endfunction

The local declared local group variable does not get nulled before function return. This will leak in JASS as pr114 has already explained.

 

[plumsy460]

What about destructible groups. Do they leak?

 

[MyPad]

Hopefully not. Unlike unit groups, destructables and items do not have their respective group equivalents, so there's no destructable group object created.

 

[Bribe]

Hopefully not. Unlike unit groups, destructables and items do not have their respective group equivalents, so there's no destructable group object created.

Correct

 

[plumsy460]

Will this leak every 2 second? Or just keep one consistent group?

PS: This is just a trigger I made up. I'm not actually using it. I'm just wondering if a new group is created if I add a new unit to a cleared group.