ComctlLib.ITreeView Active-X Memory Leak in LabVIEW

[WPS]

I have a memory leak in my Labview program - I am using the above active-x control to store a reference to data (a GOOP object), when I clear the tree (including deleting all references/objects) the active-x control doesn't appear to be releasing memory. I have narrowed down the problem to the active-x control via case statements etc and am 100% certain that all the references etc created are being deleted, (when I don't use the tree but still create and delete data objects there is no memory leak).
I am storing about 400 references in the tree, they get stored and deleted continuously and have used Windows 2000 performance monitor to watch the leak.
I can't send any code as the program contains 3rd party proprietary
information but I am wondering if anyone has any suggestions or knowledge on how to force an active-x control to release memory?
I have tried to use the MS TreeView controls but have had GUI related problems with these controls - are there any other TreeView controls around that can be used in LabVIEW?
Any comments would be appreciated.

[Cult of Nurse's]

Did you try using the 'Request Deallocation' built-in? It's on the same
palette as 'swap bytes'.

WPS wrote:
> I have a memory leak in my Labview program - I am using the above
> active-x control to store a reference to data (a GOOP object), when I
> clear the tree (including deleting all references/objects) the
> active-x control doesn't appear to be releasing memory. I have
> narrowed down the problem to the active-x control via case statements
> etc and am 100% certain that all the references etc created are being
> deleted, (when I don't use the tree but still create and delete data
> objects there is no memory leak).
> I am storing about 400 references in the tree, they get stored and
> deleted continuously and have used Windows 2000 performance monit
or to
> watch the leak.
> I can't send any code as the program contains 3rd party proprietary
> information but I am wondering if anyone has any suggestions or
> knowledge on how to force an active-x control to release memory?
> I have tried to use the MS TreeView controls but have had GUI related
> problems with these controls - are there any other TreeView controls
> around that can be used in LabVIEW?
> Any comments would be appreciated.

[Ben]

'Request Deallocation' built-in

Is this something new in LV7?

Ben

[Greg_McKaskle2]

> 'Request Deallocation' built-in
>
> Is this something new in LV7?
>

Yep. It replaces the Deallocate memory as soon as possible
Tools>>Options setting which always caused problems because it was too
global in scope. This node will schedule for subVI memory to be
released when the subVI this node is in completes. This means that if
it does something memory intensive, and you decide you don't want those
temporary buffers to be held onto to use as a cache for the next call,
you can place this node somewhere in code that executes on your diagram.
If you make multiple calls and you know when this is the last call,
you can optionally execute it just on the last call.

I don't think this will help with the ActiveX problem. The prob
lem
sound to me like you are expecting clearing the tree to know what was
stored in it, and to contact the GOOP manager and deallocate the
reference values. The tree doesn't know enough to do that. You will
need to deallocate the references yourself, then clear the tree.

As for using a different tree control, LV7 also has a LV native one.

Greg McKaskle

[Ben]

Thank you Greg.

I am in the middle of a multi-month project that is keeping me developing in 6.1.

Ben

[WPS]

Thanks for the comments Greg, but I too am limited to LV6.1 for what I am doing as development has started already for a longer project. The problem isn't related to the GOOP manager, I traverse the tree recursively and delete these references within my code before clearing the tree and have the deallocate memory as soon as possible selected. The problem lies directly with not being able to release the memory allocated to the Active-x component, clearing the tree doesn't appear to do this - thanks again.

[Greg_McKaskle2]

> The problem lies directly with not being able to release the memory
> allocated to the Active-x component, clearing the tree doesn't appear
> to do this - thanks again.

You might look around for another method that releases the tree's
temporary buffers, turn off the LV Deallocate Memory Option -- it won't
solve this problem and just causes performance and fragmentation
problems. In LV7 this option has been removed.

Another possibility is that the control hasn't truly leaked the memory,
but is instead caching it. If you do the same test several times, does
the memory usage continue to climb, or does it plateau, like a cache will?

Greg McKaskle

[WPS]

Greg,
I have run the program in a loop and monitored the memory to check for caching - it just kept climbing and eventually swaps to disk. I will turn off the deallocate memory as you are right with that one.
Cheers,
Wayne

[Michel]

Deallocate Memory Option removed...
- hmmm -
In some cases this was the only possibility to run applications longer than
for a few days....


Robert

"Greg McKaskle" schrieb im Newsbeitrag
news:3EF84B25.8070300@austin.rr.com...
> > The problem lies directly with not being able to release the memory
> > allocated to the Active-x component, clearing the tree doesn't appear
> > to do this - thanks again.
>
> You might look around for another method that releases the tree's
> temporary buffers, turn off the LV Deallocate Memory Option -- it won't
> solve this problem and just causes performance and fragmentation
> problems. In LV7 this option has been removed.
>
> Another possibility is that the con
trol hasn't truly leaked the memory,
> but is instead caching it. If you do the same test several times, does
> the memory usage continue to climb, or does it plateau, like a cache will?
>
> Greg McKaskle
>
>

[Greg_McKaskle2]

> Deallocate Memory Option removed...
> - hmmm -
> In some cases this was the only possibility to run applications longer than
> for a few days....
>

Yep. Elvis has left the building. It was pointed out in another post,
and hopefully in the upgrade notes that the Advanced>>Data Manipulation
palette has a replacement. Placing this icon in every single subVI will
have the same effect as the Option setting. With a bit of thought, you
can probably look at your app and find a few key places to place this
icon that will affect performance less dramatically and keep the memory
usage in check.

And of course I'd recommend starting with zero usage of it and see if it
is really needed. Seriously though,
placing it in a subVI that used a
large amount of memory and will not be run again for some time is the
primary usage you should look for.

Greg McKaskle