New Leak Found: Keeping references to destroyed objects.

[Troll-Brain]

But it's not like recycling all handles is always good or even possible (in an enough efficient way at least) ^^

 

[Jesus4Lyf]

The most practical problem with this is things like units being removed from the game, there are probably references to them and you don't know when they will be removed. :nuts:

Don't even know if fixing that is practical.

 

[Azlier]

>But it's not like recycling all handles is always good or even possible (in an enough efficient way at least) ^^

There are really only three unrecyclable types: Destructable, Trigger (in most situations), Trackable.

BTW, does this leak thing affect pseudohandles?

 

[Jesus4Lyf]

I'd like to add to that list: most units. Being realistic.

>BTW, does this leak thing affect pseudohandles?
I assume you mean non-agent handles. And I didn't test them.

 

[phyrex1an]

Jesus4Lyf: Can you add a test for unit references inside unit groups? Mostly for the sake of completeness.

 

[jwallstone]

"psuedo-agents", if you mean non-agent handles, should not leak. They cannot be created or destroyed and are not reference counted anyway.

EDIT: Just to clarify: does this leak happen only with waits (i.e, explicit waits or just plain waiting until later)? What if there are longer function calls between destroying and nulling? And what about the use of ExecuteFunc before nulling?

I guess in general this means non-constant global variables should never be left hanging. Mental note: null globals after use.

 

[Vexorian]

I am 99.999% sure this is a regression from the many attempts at blizz to fix the old I2C vulnerability.

Cause we've had tests about these leaks in the past and this did not happen. (Else we would have found out earlier I am really think so). Hence the reason nobody ever nulled globals before. (I mean really, we were sure setting something to null would deterministically lead to the destruction, also, pipedream messed up with the ref counter code a lot, he would have found out)

I'll try asking the blizz guy to confirm if this could be new or not.

I recommend not doing anything about it, it is silly at best to worry that much. Memory has stopped being a really big deal some ages ago. I say this because fixing it for a couple of things (many things) is not going to be possible.

Edit: "handle id" leaks are RAM leaks as well...

 

[Jesus4Lyf]

I recommend not doing anything about it, it is silly at best to worry that much. Memory has stopped being a really big deal some ages ago. I say this because fixing it for a couple of things (many things) is not going to be possible.

Agreed.

Please let us know here what Blizzard's response is when you get a reply.

@phyrex1an
I can test that when I get home.

Edit:
>Edit: "handle id" leaks are RAM leaks as well...
I know. What would you call a RAM leak that isn't a handle id leak?

 

[Vexorian]

Just call them leaks.

Err, I don't have time to test, so maybe you can reply:
* Does the handle id get recycled correctly?
* What's the extent of the leak? Is it as bad as if you didn't destroy the handle or as bad as if it was a local not set to null?

 

[Jesus4Lyf]

>* Does the handle id get recycled correctly?
Yes. Handle counter (creating 100 handles) returns the same values for the last handle before and after.

>* What's the extent of the leak? Is it as bad as if you didn't destroy the handle or as bad as if it was a local not set to null?
I don't have WC3 on me right now (can't compare what you asked) but it seems pretty minor. It's about 8k RAM per second on an every 0 seconds timer, which I think should come to around 1 byte for each occurance (iirc). Very minor.

 

[Troll-Brain]

@Azlier :
If you use many types of unitids in your map, recycling units is a silly bad idea.

We don't always need the fastest way, sometimes (and in fact most of time) the easiest, even if it involves creation/destruction of handles, is just fine.