Leaking when loading location into local loc p ?

[Ardenian]

local location p = LoadLocationHandle( hash, i, i2)

//actions

call RemoveLocation(p)
set p = null

That's how I learned to fix the .. was it the agent leak or reference leak ?
Anyways, If I use the three lines above in my function, it does not work.
Upon commenting out the last two lines, the leak fixing ones, it does.

That being said, I cannot fix the location leak properly ?

I don't understand one thing: I read that locations saved in a hashatble are not newly created, that being said, removing and fixing the leak will erase them from the hashtable.

So how do I fix the leak and as well prevent the saved hashtable location being erased ?

 

[IcemanBo]

A local agent was declared, so it has to be nulled at the end. That's correct.

But the location itself IS the same location that was stored in the hashtable.
When you remove it, then you can't use it anymore.
However, you don't leak it, because you still will take usage of it later (probably),
so there is no reason to remove the location inside your example function.
Just null it.

However, you also could store reals (x/y) into hashtables insteasd of location.
Later you can directly read out or the x/y values or even create a Location(x/y) if needed.

 

[Ardenian]

But if I would load the location into a global variable ? Wouldn't setting that global variable elsewhere cause a leak ?
Or can I imagine it like an apple hanging from a tree, with the tree being the hahstable and the apples the stored locations ? If I point from one apple to another, then the other one will remain. Removing it means pick them and removing completely form the hashtable, no matter if local or global ?

Thank you!
Well, in my circumstances I would need two hashtables then, feels a bit odd.

 

[DD_legionTN]

But if I would load the location into a global variable ?Wouldn't setting that global variable elsewhere cause a leak ?

Its the same as load it into local variable. Global can still leaks like local, but it doesn't consider as leak as global variable get new pointer every time reuse while local doesn't. So there is nothing to worry about as long as location is properly removed before reuse it.

Or can I imagine it like an apple hanging from a tree, with the tree being the hahstable and the apples the stored locations ? If I point from one apple to another, then the other one will remain. Removing it means pick them and removing completely form the hashtable, no matter if local or global ?

Even if you removed the location through RemoveLocation, as long as the pointer to the location handle doesn't get nulled, then a pointer leak will be created, depend on the amount of pointer points to the location handle. To remove a location or any other handle pointer from a hashtable, simply use RemoveSavedHandle

Well, in my circumstances I would need two hashtables then, feels a bit odd.

Hm? Why?

 

[IcemanBo]

^This.

And yes, removing the loaded location is like removing also the object "apple" from the tree (pool).
The apple can still hang around there and you might use it over again when needed. No need to remove it.

I share the thought of DD_legionTN, why 2 hashtables are needed.? Have you thought of using reals instead of locations?

 

[Ardenian]

Thanks guys, I got it!

Because 'all' slots of the hashtable are filled with locations, so I could only save one real.

 

[IcemanBo]

But child key 0 and chilkey 1 could be used. One for x and one for y.

 

[Ardenian]

But child key 0 and chilkey 1 could be used. One for x and one for y.

Sadly not, as each parent key is filled with locations.

Hm, but I could save the y coordinate as 'child key = amount of entries + n', that should work, thanks