Memory leaks using active X

[beuvink]

I experience memory leaks when using activeX components. The selected item property creates a new reference each time. Disposing this does not work since the Task manager shows that more-and-more memory is used all the time.

The only work around I can think of is to make a global variable a single time containing the reference and then use this.

But of course I do not really like this solution. Is there a better one?

[Wiebe@CARYA]

Hi,

Your example doesn't create a memory leak on my PC (LV7). Normally, closing
the activex container itself generates an error, but if I don't close it the
example does create an error....

The Selected Node returns a reference to (a copy of) the currentlly selected
node. (This is the normal behavour) So by making a global of this value, the
reference will always refer the first selected node (probably nothing, since
nothing might be selected at first).

Regards,

Wiebe.

"beuvink" wrote in message
news:506500000008000000D4BC0000-1073519706000@exchange.ni.com...
> I experience memory leaks when using activeX components. The selected
> item property creates a new reference each time. Disposing this does
> not work since the Task manager shows that m
ore-and-more memory is
> used all the time.
>
> The only work around I can think of is to make a global variable a
> single time containing the reference and then use this.
>
> But of course I do not really like this solution. Is there a better
> one?

[Sean_C.]

Hello Beuvink,

Thank you for contacting National Instruments.

To prevent the memory leak, you should not put activeX controls in a while loop. It takes memory to call the reference to the activeX object. Your VI will call a reference for each iteration of the while loop. You can slow down this leak by increasing the wait function.
If you put the property nodes and the close reference VI in an event structure, the loop will only complete an iteration for each click of the mouse on the activeX control. This seems to prevent noticeable memory leak. I am attaching the altered VI.

Let me know if you have any questions.

Sean C.
Applications Engineer
National Instruments

[monachus]

Hello!

Is the solution that Sean provides, a way to really eliminate the memory leak or only a way to reduce the ActiveX-calls and therefore slow down the increase of the memory leak, ideally as far as making it unnoticable in the runtime of the labview program?

I seem to have a similar problem where the ActiveX-call is not part of the user interface but included into the process. Thus I cannot reduce the number of calls without cutting functionality.

Any help to get rid of these memory leaks (and find their producers) I would heavily appreciate!

Thanks,
Jan

[pgstein]

Hate to beat a dead horse, but I was wondering if this issue has ever really been resolved.  I am using LabVIEW 8.2 with Active-X calls in a while loop, and my VI is using about 4K/sec of memory.  Ive tried everything I can think of.

Paul

[bburress]

Hey Paul,
      Can you narrow down the source of the memory leak?  Maybe start with a fresh VI and build it up until you see the problem show up again.  Then we can see what part of the code is causing the leak. 

[Rob_Calhoun]

LabView will leak memory unless you close every object reference in the ActiveX call. This includes both
object references that you explicitly opened with the "Automation Open" call and those that were opened
implicitly by reading a property or calling a method that returns an object reference. Every refnum wire
that you see must have an explicit close function. (You will, therefore, have many more "close" operations
than "open" operations.)

This behavior is different from languages like Visual Basic, where objects are automatically garbage
collected when they go out of scope or when the reference count goes to zero (usually when the parent
object is released.)

If you don't close the reference, LabView will not do it for you. Since the child objects become completely
unreachable after you release the parent, I don't think this is a particularly good implementation, but you

should be able to clear up your memory leak by assiduously closing every object reference.

I've attached a VI (LV 7.1) to demonstrate how an unclosed reference causes a leak. The attached VI parses
some XML using Microsoft's MSXML6 library. You may need to download MSXML6 from:

http://www.microsoft.com/downloads/details.aspx?familyid=993c0bcf-3bcf-4009-be21-27e85e1857b1&displa...

By default I close the XMLDOMMode Object after using it. Click the "leak" checkbox to retain the object. LabView will

not release it when the parent object is released, or even when the VI itself is removed from memory (!). Run it like this
in a loop and you can burn 90 MB of memory in no time.

Notes when testing for memory leaks:

 * Always start with a fresh launch of LabView.
 * Always wait for LabView to finish background loads of palettes, etc. These look JUST LIKE a memory leak.
 * Use the Task Manager to monitor cpu, memory usage. (You'll see when LabView has finished loading; cpu -> 0).
 * Expect memory usage to jump when the ActiveX component is first called. You won't get all of this
   memory back, even if you remove the VI from memory. Whether this is a result of caching for performance
   or a bug, I do not know. In practice, the one-time memory usage is not a big deal.
 * The task manager's memory usage resolution is fairly coarse, so you'll need to call whatever you
   are doing in a loop to magnify the effects of the leak.

 * After the first call, LabView.exe's memory usage should be constant. If it grows every time you click the "Test"

   button, you still have a memory leak. Review your code for missing close operations.

-Rob Calhoun

Thanks to Jason Dunham for helping to track this down.

[Rob_Calhoun]

Trying again to attach example...

[pgstein]

Thank you everyone for your help.  I got it nailed down.  I did not realize that I had to close a reference for everything, even for properties.  Now if I run my application, the memory usage will level off after about 2 minutes and stay constant.  Thanks for your help.

Paul

[ChuckS]

Sean C.

Could you give a way we can trap the leak? Most code I have ever used runs in a loop, so there is no way to avoid looping over code, including activex.

Thanks