Active X dll calls cause Memory Leak in reentrant mode?

[DailyDose]

I have an application that uses the super old but apparently reliable OPCDAAUTO.dll that can be registered to Windows and used in LabVIEW via Active X.  The application we've written calls our OPC wrapper as a library/driver.  The OPC wrapper is reentrant - reallocate.  We've been seeing some pretty significant memory leaks in this application and I've gone through all refs and shift registers to see where the leak is.  At the point of grasping straws, I am wondering about the reentrant property.  Is it possible that the fact this "Driver" being reentrant is my memory problem?  Continuously calling an Active and reallocating memory to do so?  I'm not sure I fully appreciate or understand the behavior of reallocate reentrant.  Any help here would be hot.

[Norbert_B · Accepted solution]

Well, reentrant execution will increase memory consumption as each concurrent execution requires its own data space. That being said, this is NOT a memory leak.

If you observe continuously growing memory consumption, there are a couple of possible reasons:

a) Memory fragmentation: Due to block-addressing of memory and constraints of specific data types (arrays), memory can fragment. That means that repetative, increasing sizes of memory blocks are allocated. This is not a leak, but could bite you with "System out of Memory".

b) Object leak: ActiveX is by default OOP. If you create objects (can be done by calling methods or properties of other objects) but never release them properly, they can stay in memory as "zombie". This is a leak which likely bites you quite fast, esp. if objects require a lot of memory each.

c) Reference leak: You create new references to existing objects without using existing references. These unused references require memory (~8 byte) but if not used anymore, it's a leaking behavior. Eventually bites you after extended time of execution.

d) Coninuously growing data structures: Your application collects data (e.g. for a log file) but that data is never released, even if it got written to file. This is not considered a leak, but bad programming style.

I think these should be the most obvious reasons for continuously growing memory consumption of an application. One important note: Try getting grip on the issue (esp. reference leaks) by using the LabVIEW Desktop Execution Trace Toolkit (DETT).

Norbert