• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

I have a problem with Leak Checker 3.1

Status
Not open for further replies.
Level 6
Joined
Oct 19, 2007
Messages
57
OS: Windows 7 sp 1

when i double-click to app.

then

attachment.php
 
Last edited:

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,198
Do not bother using that tool. Rather learn the mechanics behind WC3 leaks as that way you can avoid them better.

1. Loosing all references to an object that was created that the game does not destroy automatically (like a timer, location, group, force or effect) will result in the object persisting in memory but never getting used again (kind of the definition of a leak). This is the most major form of leak and what you should have none of.
2. Failing to null a local handle before the end a function will result in a counter inconsistency for the handle index recycling system (meaning that it is impossible for the handle index to be reused) causing a handle index leak (the object it referenced may be cleaned but the index that was used to refer to it will never get cleaned). Handle objects than never do get freed (removed, destroyed, cleaned etc) this logically does not apply to.
3. Like with 2, this leak is possible with globals to a very small scale if one was used a finite number of times with the handle it pointed to getting cleaned but it never getting assigned a new value. This leak source is so neglible you can probably ignore it as it is finite atmost.
4. Removing units via the RemoveUnit() native causes a leak where the resources allocated to the unit are not freed complety. Letting the unit get removed via death (usually from enabled explode then killing it) does not leak though. As Heroes do not get removed on death, removing them will always leak so consider recycling them instead (resurrecting them). This is a very new leak that was found and some say it is a bug introdued by one of the patches.
5. Forgetting to free up stored data in a hashtable or gamecache. As these structures dynamically expand to accomidate the data added to them, if you keep adding and never remove they will continiously get bigger (and slower). If the data added will never be used again then it classes as a leak.
6. Dynamically creating hashtables and gamecaches. The engine does not support this and per session you can create atmost 256 of them with a shared limit (common between both). Try using 1 as heavilly as possible instead of allocating them for each cast, instance or ability etc.
7. Dynamically creating trackables. There is no deconstructor for them so each trackable you create will remain the entire session.
8. Destroying and Recreating sounds. This just does not work properly and will cause sound leaks or unplayable sounds (bugs). Instead try to treat sound objects as constants and reuse the same object as much as possible.
9. Dynamic trigger creation. This is poorly documented and unclear whether it leaks or it just has a chance to crash the map at random.
10. Strings. Every unique (not already made) string will result in a form of leak. Although not really a leak as they will get reused next time the same string is generated, if you create enough unique strings via a dogy system this can be a problem. This is unfixable (do not care about it but avoid systems which generate lots of unqiue strings).

Well thats about all I can think of.
Some things like texttags can not really leak as they have a defined handle address range of 100 recalled in stack like fassion and so after 100 are created the last created texttag will get recycled. Yes they still can remain permantly on screen and usless like a leak but it can never grow into a major problem.
 
Status
Not open for further replies.
Top