Arrays as object properties; memory leak

[trancexx]

If arrays are used with objects as e.g. properties some sort of memory leak occurs. This seems to be specific only to Array type.
Example (monitor memory usage during execution):

$a = StringSplit("a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z", ",")

MsgBox(0, "", "start")
For $count = 0 To 10000
	$obj = ObjCreate("Scripting.Dictionary")
	$obj.add("test", $a)
	$obj = 0
Next
MsgBox(0, "", "stop")

For possible comparisons, VBS version would be:

a = Split("a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z", ",")
 
MsgBox("start")
For count = 0 to 10000
    Set obj=CreateObject("Scripting.Dictionary")
    obj.add "test", a
    Set obj = Nothing
Next
MsgBox("stop")

No leak there (or with some other languages).

[trancexx]

Just an observation more.
This seems to be related to re-initialization of the variant you use for transporting data with arrays. You reinitialize it with VariantInit (VariantInit->VariantInit->Manual setting->VariantCopy->GoAgain). In case of VT_BSTR this leads to memory leak. That's why it's not leaking if the array ($a) is array of integers.
I couldn't find much about this on msdn except for description for VariantInit saying function does not interpret the current contents. Description for VariantClear is on the other hand very specific about releasing.
Adding VariantClear as a step of reinitialization should fix the issue. At least looks that way.
If I'm off please don't mind.

[Jpm]

The VariantClear is done so it should be something else ...

[trancexx]

You have one particular class defined in the code that is closely related to arrays-objects interaction procedure.
One private member of that class is a variant whose purpose is to serve as a carrier of data from internal array to object.
That variant is not cleared on its reinitialization (nor on end_of_usage, likely).
But if you say it is then that's it. You have the code in front of you.

Btw, AutoIt code can be written based on the assumption from the above and the issue can be attempted to be solved from the script itself. Conveniently it works, but it's causing a performance hit.

Anyway, I hope you'll find the solution eventually.

[Jon]

Fixed by revision [6132] in version: 3.3.7.10