Locals...

If i declare a local variable, does it automatically get removed from memory as soon as it falls out of scope?

it wouldnt be local if it didnt

Um handles remain in memory.
You must always set a handle to null and/or try to destroy it at the end of a function.

can someone post all the Remove commands? like

call RemoveLocation( ugd_Location_var )

^thats the only one i know...

also, is there a special way to destroy unit handles without destroying the actual unit?

setting it to null means the local is derferenced.

Thats the best you can do handles for some reason do not get dereferenced or destroyed at the end of a function.

You can destroy the unit later...

I have been wondering this, if you destroy a trigger are all locals in it cleared, or are they still in memory? And also, how do you set a local variable, say of type location, to null at the end of the function?

At the end of a function all handle vars set to null are the equivalnt of being destroyed. However, that does not mean that if you created a location set it to local l then set local l to null that your location was destroyed. It still is in memory you will have to call a remove function on it. They are all found in common.j and are easy to find (search for remove)

All the non handled types are also destroyed regardless of value. If you destroy a trigger it won't be destroyed until its actions or conditions stops being run. So just set handle type to null and remove/destroy them if possible.
For your question Narwanza the answer is set (nameoflocalvar)=null

Note that there is no way to return the handle and set it to null at the same time. Functions that do this always leak tiny bit of memory. This is not a big problem, unless you use those functions a lot (at least 10,000 times).

No, not only handles remain in memory, but objects these handles are referring also remain! Setting handle to null DOES NOTHING!

Every object created inside a function remains in memory after function returns (as example: when you create new unit it's not being destroyed when function returns)! There's no difference it was declared as local variable or not!

You should destroy all local data which you don't need anymore by DestroyObject() or RemoveObject() functions.

For example: RemoveUnit(), RemoveLocation() etc...

You mean setting the local to null doesn't remove the object it is pointing at.
Is there a difference between destroying an object and destroying an object and setting the handle to null afterwards? Or is the handle null after destruction anyway?

Another question: How do you check if some functions leak? Do you just test whether the game starts to lag at some time or do you have some special methods?

When you create a unit and set the handle to null, the unit still exists, right? So it must be taking up memory. I think you have to both set it to null and eventually destroy it. Are you sure that handles passed into the function do not cause the same problem?

From that other thread, I think the best way to test leaks is to make a loop of them and use ctrl-alt-delete and view the task manager to see memory usage.

Its my experience from the leak test triggers that the setting it to null does seem to save memory.

War3 thinks that unless a local handle is completely derefenced it still might be referenced later so i guess it doesn't recycle it.

Native functions do not leak, or if they do neglibably so. anything being passed may leak, were not a 100% sure.

I have been following these conversations from the first thread about leaks in this forum.

And everybody seemed to have taken different parts of those revelations to themselves.

What i understood after reading these threads, is that setting handles to null makes the least difference....the most important thing is to always destroy everything you create. So that is waht i do, i don't set variables to null, i just destroy (and MakeTemporary) everything i create, after use.

Now, what i wonder about, as i somehow want to believe that blizzard destroys/cleans up parameterized objects when the function finishes,..that is, the "whichgroup" in the following line:

function blabla takes group whichgroup returns nothing

so it is not needed to destroy this object, but i may well be wrong.

Another thing i wonder about is with objects one returns, basicly, the oposite of what jmoritz was implying...that jass clears up objects that one returns. But again, this is just my feeling and my almost dead-by-now trust in blizzards coders.

Anyhow, i still am anxious to see some clear revelations backed up with facts so we can find a official "right" way to do things (f.ex. with destroying objects, and setting their handles to null, as noticable in the jass-vault...this part is not the same from a submitter to another, some omitt setting handles to null, while others do)

anyways......

Cubasis

Well Cub I see it this way if it might help whats one extra line of code?
setting a local to null takes absolutely no effort at all so if its effect converges towards unimportant I wasted no massive amount of effort. My function may run for an extra two clock cycles, big deal.

For the sake of organisation, some mod should merge this thread with the other thread (was it the Memory leaks thread or the local vars thread?).