[JASS] leaks?

[Vexen.X]

when creating a text tag and using the SetTextTagLifespanBJ(tag,real), does it also destroy and cleanup the tag so it doesn't leak or do I still need to call DestroyTextTagBJ(tag)

 

[donut3.5]

I'm pretty sure you have to clean it up afterwards. Couldn't hurt to do it.
--donut3.5--

 

[PurplePoot]

I'm almost definitely sure that it cleans itself up... t'would be interesting to test, though.

 

[Vexen.X]

Yeah... I been having a few issues with memory leaks and I cant find the source of the leak. Every group, location, rect, effect that is created is destroyed before the trigger finishes

this was the only thing I could find and think of

I added a manual clean up as well gonna test it later and see if there is a difference

 

[PurplePoot]

Do you deal with regions, triggeractions, triggerconditions, triggers, timers, itempools, unitpools, dummy units, lightnings, etc?

Oh, and try not to use BJs

 

[Vexen.X]

regions i only use with boolean statements IsUnitInRect(rect,unit)

triggeractions i dont generate new ones, just the ones that are associated with the init triggers as events

dont use any trigger conditions, i do everything within the trigger if needed

triggers, 90% of the triggers i use get destroyed upon use (the other 10% is repeating triggers, I dont have any that I generate on the fly)

timers, well this leads me to another question, if i use a global timer variable, do i have to destroy it every time I reset the timer and start it again... if so that is probably my issue....

groups, I destroy all of those

dummy units get removed, checked those too

lightings, other... dont really use much of that

effects, i destroy them all

and for the most part 99% of my code calls natives directly, I been fixing that slowly. I have a bad habbit of forgettin a native's name so I just grab the function from the GUI command and bring it in

 

[PurplePoot]

Nono, regions, not rects. (You probably don't use them if you don't know the difference)

Timers; no, only for locals.

Not sure, then... Sometimes leaks can be a pain to find, especially when you think you clean them but a thread crash or something causes them to occur (because the function never gets to the point where it can clean them)

 

[Vexen.X]

i know the difference, i have used them both before, i just read what you said wrong (no regions in my functions on this project... at least I dont think so... i'll have to double check that)

and yes, they are a pain in the ass to find... i'll figure this out eventually

 

[Vexen.X]

it was a multibord item that was being properly released, but the variable was not being set to null afterwards... figures

 

[PurplePoot]

You were getting terrible leaks from null..? I doubt it, but meh.

It was probably indirectly caused by null, or else that was just one of a few.

 

[Vexen.X]

when i added the set myMBItem = null at the end

the function stop leaking, it was really weird, because I never thought that something like that would leak

 

[PurplePoot]

That leaks, but it only leaks 4 bytes each time; you should be able to leak that hundreds of thousands of times no problem, probably a huge amount more.

The big problem with not nulling stuff is that it keeps its handle index, so it screws over H2I and the Local Handle Vars.

 

[Vexen.X]

well the multiboard updates every 0.25s on a timer, so if the game lasts several hours, no wonder people noticed it in the long run.

I went through over 90% of my code already and added nulling of variables that used handles (units, rects, groups, etc) mainly on the functions that repeated often, and over an hour play I noticed about a 10mb difference in the memory that wc3 used

anywho.. thanks for your help

 

[PurplePoot]

Every .25s on a timer should not cause any problems. Shouldn't even get close.

If you're getting a 10 mb memory difference, you'd have to be leaking a lot if it was only from nulls. (which I doubt... imagine how many variables you'd have to have used that you didn't null, that weren't primitive types!)

You probably have several other leaks lurking around somewhere.