Debugging and issues...

[Skyflash]

well i`m trying to debug my spell via Handle counter method
my first question : after i use spell the handle counter shows two numbers and bouncing between them which one is the correct one? one of them remains constant most of the times but the larger number increases 1 or 2 when i run that spell

my second question : how much can the handle counter be increased per spell`s execution in order to have a leakless spell?

 

[Chaosy]

To be honest I don't get what you're talking about, at all.

Maybe that's just me.

 

[Skyflash]

my bad i thought maybe anyone familiar with Debugging to find leaks

 

[SAUS]

Handles are basically pointers (if you know what pointers are from other programming languages).

In JASS, handles leak. This is why you will see stuff like:

function doop takes nothing returns nothing
    local unit u = GetTriggerUnit()
    call RemoveUnit(u)
    set u = null // <------ this line
endfunction

For question 1, I don't know. I haven't used this method before.
For question 2, I imagine it can go up any number of times without leaking (though there is an operation limit, however, you'll have bigger problems if you are hitting that - there would be huge lag spikes). You just have to make sure to null the proper variables at the end of your function.

 

[Chaosy]

Never seen that tutorial, but it would be easier to get what you mean if you share the trigger you're testing this technique on.

Because I do not believe there is a commonly used method which use a handle counter.

 

[Skyflash]

Never seen that tutorial, but it would be easier to get what you mean if you share the trigger you're testing this technique on.

Because I do not believe there is a commonly used method which use a handle counter.

Sure here is the trigger

• Debugger
  • Events
    • Time - Every 0.09 seconds of game time
  • Conditions
  • Actions
    • Set Debug = (Point(0.00, 0.00))
    • Custom script: call BJDebugMsg(I2S(GetHandleId(udg_Debug)-0x100000))
    • Custom script: call RemoveLocation(udg_Debug)

the reason i thought anyone knows this method was the moderator`s comment below my resource he mainly points to handle counter`s after a few search i found this tutorial

 

[Skyflash]

every time i opening Worldedit ,i getting more confused about this debugging method i`v tested this method on top spells in spell`s section but i found all of them leaking please help me with this ,is it a accurate method or not ? which method can guide me for finding leaks ?

 

[SAUS]

every time i opening Worldedit ,i getting more confused about this debugging method i`v tested this method on top spells in spell`s section but i found all of them leaking please help me with this ,is it a accurate method or not ? which method can guide me for finding leaks ?

Where did you find this method? It seems like it is just incrementing a memory address or something. I don't think that's a problem.

It can go up as long as there is still memory to use. If it goes too far, it would crash the game. They probably recycle at some point or something. I don't know how it works exactly.

 

[Skyflash]

Where did you find this method? It seems like it is just incrementing a memory address or something. I don't think that's a problem.

It can go up as long as there is still memory to use. If it goes too far, it would crash the game. They probably recycle at some point or something. I don't know how it works exactly.

PurgeandFire wrote a tutorial for Finding Leaks by counting the handles the increment of handles without recycling means leak and this method shows us clearly but the problem is every Pick every-UnitGroup cause leaks even if you Destroy it correctly this issue is really bothering me

 

[SAUS]

PurgeandFire wrote a tutorial for Finding Leaks by counting the handles the increment of handles without recycling means leak and this method shows us clearly but the problem is every Pick every-UnitGroup cause leaks even if you Destroy it correctly this issue is really bothering me

Okay I read through the tutorial. I will probably have to test this out myself. Are you testing this in an empty map or do you have other triggers? What numbers are you seeing?

 

[Skyflash]

Okay I read through the tutorial. I will probably have to test this out myself. Are you testing this in an empty map or do you have other triggers? What numbers are you seeing?

well the initial number dosen`t matter at all the increment of this number indicates the number of leaks per Periodic loops my system runs smoothly without unitGroup-Related function ,my counter starts approximately from 490 and ends 517 after long time using system this means it`s almost leakless but when you use pick-everyunit function the number will increase permanently that`s why i get worried every time

 

[SAUS]

well the initial number dosen`t matter at all the increment of this number indicates the number of leaks per Periodic loops my system runs smoothly without unitGroup-Related function ,my counter starts approximately from 490 and ends 517 after long time using system this means it`s almost leakless but when you use pick-everyunit function the number will increase permanently that`s why i get worried every time

Pick every unit in <region> create a unit group and leaks it. You can use the "bj_wantDestroyGroup" (I don't know if that is the actual variable name) flag when using these functions - blizzard put this flag in to indicate that you do not want to keep the group hanging around at the end.

Alternatively, you can manually delete those groups by first assigning them to a group variable and using DestroyGroup() on that variable after you are done using it.

I can't tell you what is leaking without seeing all your triggers, and that might be a long process (especially since it seems like it would be a minor thing). I think even creating units would increase this number and only go back down when they die and then fully decay (I don't know how it all works, so I could be wrong).

27 leaked handles "after long time using system" as you say is really not that many (unless you plan to run your map for waaaay longer than that).

 

[Skyflash]

Pick every unit in <region> create a unit group and leaks it. You can use the "bj_wantDestroyGroup" (I don't know if that is the actual variable name) flag when using these functions - blizzard put this flag in to indicate that you do not want to keep the group hanging around at the end.

Alternatively, you can manually delete those groups by first assigning them to a group variable and using DestroyGroup() on that variable after you are done using it.

I can't tell you what is leaking without seeing all your triggers, and that might be a long process (especially since it seems like it would be a minor thing). I think even creating units would increase this number and only go back down when they die and then fully decay (I don't know how it all works, so I could be wrong).

27 leaked handles "after long time using system" as you say is really not that many (unless you plan to run your map for waaaay longer than that).

well i know how to remove group leaks but the problem is the handle exists after destroying Group very weird but it still count them
i used 2 methods to remove them

First Method (Leaking)

• Set TempGroup = (Units within Damage_Radius[TempInt] of TempLoc)
• Unit Group - Pick every unit in TempGroup and do (Actions)
  • Loop - Actions
    • Set tempunit = (Picked unit)
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • (tempunit belongs to an enemy of Player[TempInt]) Equal to True
      • Then - Actions
        • Unit - Cause Unit[TempInt] to damage tempunit, dealing 100.00 damage of attack type Spells and damage type Normal
      • Else - Actions
    • Custom script: call RemoveLocation(udg_TempLoc)
• Custom script: call DestroyGroup(udg_TempGroup)

Second Method (Leaking)

• Custom script: set bj_wantDestroyGroup=true
• Unit Group - Pick every unit in (Units within Damage_Radius[TempInt] of TempLoc) and do (Actions)
  • Loop - Actions
    • Set tempunit = (Picked unit)
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • (tempunit belongs to an enemy of Player[TempInt]) Equal to True
      • Then - Actions
        • Unit - Cause Unit[TempInt] to damage tempunit, dealing 100.00 damage of attack type Spells and damage type Normal
      • Else - Actions
    • Custom script: call RemoveLocation(udg_TempLoc)

 

[SAUS]

I think I found the problem. You'd have to move the code to JASS to fix it.

Check this page (it is the source code for the blizzard.j JASS file):
http://jass.sourceforge.net/doc/api/Blizzard_j-source.shtml

On line 4451:

//===========================================================================
function GetUnitsInRangeOfLocMatching takes real radius, location whichLocation, boolexpr filter returns group
    local group g = CreateGroup()
    call GroupEnumUnitsInRangeOfLoc(g, whichLocation, radius, filter)
    call DestroyBoolExpr(filter)
    return g
endfunction

//===========================================================================
function GetUnitsInRangeOfLocAll takes real radius, location whichLocation returns group
    return GetUnitsInRangeOfLocMatching(radius, whichLocation, null)
endfunction

My guess is the "Units in range of <point>" translates to the GetUnitsInRangeOfLocAll function (the second one in the snippet). That function then calls the one above GetUnitsInRangeOfLocMatching. In that function, it creates a group handle local group g = CreateGroup(). In JASS, at the end of your function, you have to set all your handle variable to null or those handles are never released. Blizzard didn't do this, so the top function in the snippet leaks a group handle even if you destroy the group.

 

[Skyflash]

I think I found the problem. You'd have to move the code to JASS to fix it.

Check this page (it is the source code for the blizzard.j JASS file):
http://jass.sourceforge.net/doc/api/Blizzard_j-source.shtml

On line 4451:

//===========================================================================
function GetUnitsInRangeOfLocMatching takes real radius, location whichLocation, boolexpr filter returns group
    local group g = CreateGroup()
    call GroupEnumUnitsInRangeOfLoc(g, whichLocation, radius, filter)
    call DestroyBoolExpr(filter)
    return g
endfunction

//===========================================================================
function GetUnitsInRangeOfLocAll takes real radius, location whichLocation returns group
    return GetUnitsInRangeOfLocMatching(radius, whichLocation, null)
endfunction

My guess is the "Units in range of <point>" translates to the GetUnitsInRangeOfLocAll function (the second one in the snippet). That function then calls the one above GetUnitsInRangeOfLocMatching. In that function, it creates a group handle local group g = CreateGroup(). In JASS, at the end of your function, you have to set all your handle variable to null or those handles are never released. Blizzard didn't do this, so the top function in the snippet leaks a group handle even if you destroy the group.

Yes they just forgot to set g = null i know it`s sounds funny but i don`t know how to rewrite these stuff in jass (in custom script) i don`t know how to use ForGroup function in jass either
by the way thanks to inform me i thought i don`t using a proper method in order to remove leaks

 

[SAUS]

Replace this line in your first trigger:

• Set TempGroup = (Units within Damage_Radius[TempInt] of TempLoc)

with this:

• Custom script: set udg_TempGroup = CreateGroup()
• Custom script: call GroupEnumUnitsInRange(udg_TempGroup, GetLocationX(udg_TempLoc), GetLocationY(udg_TempLoc), udg_Damage_Radius[udg_TempInt], null)

It is a bit daunting since it is a long line of code, but it will do the same thing as the GUI function you are using and won't leak a handle. Everything else in your trigger should be the exact same.

 

[Skyflash]

Replace this line in your first trigger:

• Set TempGroup = (Units within Damage_Radius[TempInt] of TempLoc)

with this:

• Custom script: set udg_TempGroup = CreateGroup()
• Custom script: call GroupEnumUnitsInRange(udg_TempGroup, GetLocationX(udg_TempLoc), GetLocationY(udg_TempLoc), udg_Damage_Radius[udg_TempInt], null)

It is a bit daunting since it is a long line of code, but it will do the same thing as the GUI function you are using and won't leak a handle. Everything else in your trigger should be the exact same.

OMG! Worked Finally I achieved 0 leak! thank you!