memory leaks in NI-DAQ 6.9.1

[FoxGui]

Can anyone tell me if the API for NI-DAQ 6.9.1 has been purified to eliminate all memory leaks? I'm using DIG_Block_In() etc. with PCI-653X DIO cards. My Win2K MSC++ V6 Purify (tm) reports many potential leaks similar to the following:

[I] MPK: Potential memory leak of 11550 bytes from 350 blocks allocated in RegistrySession::~RegistrySession(void)
Distribution of potentially leaked blocks
11550 bytes from 350 blocks of 33 bytes (first block: 0x04a34ae8)
Allocation location
malloc [msvcrt.DLL]
RegistrySession::~RegistrySession(void) [nipsm.dll]
moot::moot(basic_string,allocator> const&) [nipsm.dll]
moot::moot(basic
_string,allocator> const&) [nipsm.dll]
moot::load(PSMQueue&) [nipsm.dll]
BinaryFileProxy::Load(PSMQueue&) [nipsm.dll]
BinaryFileProxy::Begin(void) [nipsm.dll]
KeyProxy::Open(moot const&,DWORD) [nipsm.dll]
CfqCloseConnectionToServer [nicfq32.dll]
CfqQueryDigitalAvailability [nicfq32.dll]
moot::moot(basic_string,allocator> const&) [nipsm.dll]

[John N]

Hi fox,

NI-DAQ 6.9.1 has certainly been refined through past revisions, and whatever memory leaks we have found we have fixed.

Here, I think it would be good for you to translate the output of Purify to let everybody here know what the implications are. Maybe others are familiar with Purify, but I am not. For instance, does the output implicate certain libraries (there are a lot listed) as leaking and list others as just involved, but not leaking? Or are all libraries listed suspected of leaking memory?

This might give us more to work with.

Thanks,

John Nieri
Applications Engineer
National Instruments

[FoxGui]

John,

Thanks for your reply. I'll include another Purify "Potential Leak" report and try to annotate it more.

This is the biggest reported leak at 11550 bytes from the destructor of an object called RegistrySession found in nipsm.dll.

The lines below "RegistrySession::~RegistrySession(void) [nipsm.dll]" form a call stack reading down. ie object moot called RegistrySession, and BinaryFileProxy::Load() called that, etc. The RegistrySession destructor is really the only culprit for allocating memory then losing it. The whole chain of events starts, however, at a call to CfqQueryDigitalAvailability in the nicfq32.dll.

Now, my application certainly didn't call this and I have no idea what it's trying to do, but I suspect that it's called sometime
during the loading and initialization of nidaq32.dll which I link against.

If you indeed Purify your libraries prior to release then you should be able to duplicate my results.
I can send you my code if you like.

Thanks for you help,
Dan Stine



MPK: Potential memory leak of 11550 bytes from 350 blocks allocated in RegistrySession::~RegistrySession(void)
Distribution of potentially leaked blocks
Allocation location
malloc [msvcrt.dll]
RegistrySession::~RegistrySession(void) [nipsm.dll]
moot::moot(basic_string,allocator> const&) [nipsm.dll]
moot::moot(basic_string,allocator> const&) [nipsm.dll]
moot::load(PSMQueue&) [nipsm.dll]
BinaryFileProxy::Load(PSMQueue&) [nipsm.dll]
BinaryFileProxy::Begin(void) [nipsm.dll]
KeyProxy::Open(moot const&,DWORD) [nipsm.dll]
CfqCloseConnection
ToServer [nicfq32.dll]
CfqQueryDigitalAvailability [nicfq32.dll]

[ssanto]

Just to let you all know... NI-DAQ 6.9.2 is available for download.

-Sal

[FoxGui]

Ok,

Just installed 6.9.2. All of the above leaks are still there.... plus some new ones.

I can live with a few K being lost during startup, but if any routines in my main loop leak I have no hope of producing a reliable application for shop-floor operational use.

Dan

[John N]

Hi again Fox,

Thanks for the explanation. That makes a lot more sense now that I know it's a call stack.

Have you observed operation of the program over time? The report says "potential" memory leak. I am not trying to say there is no possibility of a memory leak, but is it possible that the reported memory remains constant or grows and shrinks with usage of the dll? If the size of memory seems to have a predictable size and go away after usage of your program, it could just be normal use that Purify isn't recognizing.

This is the debugging nature in me, so bear with me if it sounds like I am denying the memory leak. I am just trying to strip away other possibilities.

Best Regards,
John

[FoxGui]

John,

Purify is actually quite sophisticated in that it records every block of memory that is allocated by a program/library/dll and then goes back and analyzes it's list at program termination time to determine if any of those blocks have not been freed. As you correctly point out the "potential" in the memory report implies that Purify cannot say for sure that heap is being consumed. The documentation says:

[Quote]

potential leak (Visual C/C++)

Allocated memory to which there is no direct pointer (pointer that references the start of the block), but for which there is a pointer to some other location within the allocated block.

In order to free this memory, the program must subtract an offset from the p
ointer to the interior of the block. In general, you should consider a potential leak to be an actual leak until you can prove that it is not by identifying the code that performs this subtraction.

[End quote]

Since the NI code could be doing any number of strange things that are perfectly correct (like keeping a private heap) and since I don't have any ability to compile the DLLs with debug information it's very hard for me to analyze this problem from my end. It is at this point that I would start looking at the source of those functions mentioned by hand to see if any of them leak. If I had access to the source... that is.

I can certainly measure actual memory lost over time, but how should my program be coded if the NI code consumes my memory? Should I put up a dialog that asks the operators to restart the program every couple of days just to clean up the mess?

I use multiple third party code in my application and IMHO all vendors who don't release source code are s
uspect. What I really want is some quality assurance from NI that they resonably test the API code and fix reported problems.

[John N]

FoxGui,

I am posting a new response to the original question since I have found a more direct answer now. I found that the memory leak there with nicfg.dll is known, but that the leak will not grow because nicfg.dll won't be used more than once in a session (loading configuration information with MAX).

So Purify was definitely correct that it found the leak, and our discussion was also valid since the size of that memory shouldn't grow.

We are addressing that in an upcoming release of NI-DAQ.

Regards,

John Nieri
Applications Engineer
National Instruments

[John N]

Hi again Fox,

I wrote a large new response to this several weeks ago, but I just found it did not post. I'll try to remember the meat of what I put in that post.

The issue at the heart of this, I found, is one that was already reported and being looked at. Whatever the source of it, the apparently lost memory does not grow. Whenever the NI-DAQ dll is loaded and used, the behavior you saw can occur, but it should not grow. So just to let you know - we are on it.

Similarly, in response to your last comment in our previous discussion, we definitely do test all of our software and respond to internal and external discovery of issues with the software. In fact, we have a well organized system in which we can investigate, reproduce, and report suspected issues with
software and hardware.

Sorry for the long delay in answering it. I thought my reply was long since made.

Regards,

John N
Applications Engineer
National Instruments