Leaking Variables...

Ok. Does a local which does not get used, but is nulled at the end of the function, leak?

Example:

Now, let's say 'A' is NOT equal to true when this runs. According to War3err, 'u' would be an uninitialized variable. Since it's nulled anyways, does that leak at all?

While I'm at it, is there a dummy value I could set something like an effect variable to (would null work?), so that I don't get War3err errors everytime a passive runs and doesn't set the effect variable to anything (because it didn't pass the check)?

You've misunderstood what a leak is. Technically, variables don't leak, what they point at can be leaked. http://en.wikipedia.org/wiki/Memory_leak

Essentially, you create some structure, then lose any reference to it. Now you can't find it to clean it up, but its still sitting in memory. (It will be cleaned when the game ends, because WC3 keeps track of it. If WC3 leaks it too, your OS will clean it when WC3 ends.)

I doubt there is any map ever that leaked units. It would be incredibly obvious when units started being created constantly but never removed. Also, you can't lose the reference to a unit because you can iterate over all of them.

+ the object IS removed ! BUT the handle of this object is not recycled (generic handles units,triggers etc.). END of the story.
// if you use gamecache so any new handle will create (in gc usage) new string == extra memory needed. in truth it's not really seriously.

It is not that easy. Since Jass allows/requires the user to destroy objects it could cause access violations if you tried to do something on a handle that was already removed. What war3 does is to use a reference counter for the handle objects, if you remove a handle it gets replaced with some 4 bytes ghost that holds that memory space until no variable references to it.

The problem is, that for some odd reasons blizzard does not decrement the reference counter when locals go out of scope, so you need to set them to null else these ghosts will leak and your handle ids will raise unnecessarily high.

Not a believer? try this:


Compare memory usage by A and B.

In this case , darkwulfv if the variable is not ever assigned (not confuse with used) it will not even require to be assigned to null. But if it does get assigned to a handle that is "living" then it requires to set to null.

If you take a local variable, do not ever use it and then assign it to null by the end of the function, it doesn't 'leak'

Ok, Vex answered my question plain and simple. Thank you.

I assumed Blizzard would actually do that correctly. I guess I should have picked up on the pattern by now.

I guess I'm too used to languages like C spoiling me with memory management (that is sarcasm, by the way).

Doesn't War3err only warn you of uninitialized variables?

World Edit would only stop you if the number is not initialized. The value of u would be initialized so there would be no error...

WE wouldn't detect it.

Damn typo! I meant:

Allrighty then, let's review. War3err tells you you have an uninitialized variable. That's very bad, because it means you are trying to do something with this uninitialized variable, which without war3err causes a thread crash. You should initialize your variable with a null value.

Also, uninitialized variables have nothing to do with leaks, I don't know where you got the correlation.

All I'm trying to do to the variables is null them at the end. Bah. If they don't get set to anything (thus uninitialized) because they get set inside an If/then (and the if returns false), all I'm doing to them is nulling them. But if it causes a thread crash, that would probably mean the remaining variables that need to be nulled would not be.

Setting the variable to null when it's called ('local thing x = null') will fix this, correct?

...setting a non-initiated variable won't cause a thread crash. If it did, no variable could ever be set...

What we're saying is that if War3err reported an uninitialized variable use then you most likely tried to do something more with it than just set it. We can't know for sure because you haven't posted the whole function.

But yes, giving an initial null value to it would avoid all danger of uninitialized variable use.

Try the new grimoire. If your function is largely driven by its arguments, the uninitialized var use will throw a stack trace showing what data caused it to fail. If the data comes from globals or callback functions, you can use the debugger to step to the failure point and find out exactly where it goes wrong.