memory leak labview real time cFP

[DrMike]

I've been given the task of getting another developer's code running on a cFP2120.  The application currently has a memory leak.  Previous discussion zone posts indicate that using build arrays with shift registers should be avoided.   I'm going to go through the code and modify everything that could be a memory leak source as this app needs to have rock solid stability.  I'm hoping to get a list of everything else I should be looking out for.  Previous posts indicate that coercion dots cause leaks too.  Is this correct?  What about explicit coercion functions?  The code does floating point calculations using the I32 tick count and so trying to remove every coercion in the code will be a real pain and I don't want to have to do this unless it is absolutely necessary.

Can I assume the concatinate string function calls (with shift registers) will also have to be replaced with replace string subset functions?  What about functions like "flatten to string" - does this leak?  (We really get spoiled using LV on a PC and not having to worry about memory management.)  Can I assume unbundling is leak free?

Finally, previous posts

http://forums.ni.com/ni/board/message?board.id=110&thread.id=6032&view=by_date_ascending&page=1

seem to indicate that lots of individual channel cFP reads and writes can also cause leaks - and this is exactly how this app was written.  Does anyone know if this is something I will need to redo also?

[David_B]

The KnowledgeBase article Determining When and Where LabVIEW Allocates a New Buffer discusses in detail how to minimize all your new buffer allocations.

New to LabVIEW 8.5 is the In Place Element Structure. 

I hope this gives you adequate resources to optimize your program.

[DrMike]

David_B

I am already quite familar with buffer allocations and memory management in LV (been using full time since ver 2.5).  My questions are specific to memory LEAKS on the Real-Time operating system.  Someone at NI should be able to tell me the known sources of memory LEAKS on RT such as the build array I previously mentioned.

[David_B]

My apologies DrMike,

I'll dig into this a little deeper and see what I can find out for you.

[David_B]

Hi DrMike,

The only other leak that I've found has been fixed in LabVIEW 8.5.1 but would affect you in LabVIEW 8.5 (they were not present in LabVIEW 8.2).  This is a small memory leak when reading from or writing to network publshed shared variables.  The work around suggest prior to the fix was to use TCP/IP rather than the variables.

It may be a good idea to post this to the RT or FP forums as well and see if that specific group of users have run into any other issues that we may not have documented already.

[DrMike]

Thanks David_B.

That is the kind of information I was looking for.  The bad news for me is that the application uses network shared variables to communicate with the host.  Is there a KB or other reference you could give me regarding this known leak?

[David_B]

Actually, I had to dig deep through our R&D corrective action requests to even find the one that I mentioned.  So there is no documentation other that what I've provided in the previous post regarding it.

Is it an option to either update to LabVIEW RT 8.5.1 or revert to LabVIEW RT 8.2?  Or is it an option to possibly use TCP/IP in place of the Variables?

The CAR numbers however for this are 70893 and 59142.  If you call in to NI support and reference that number we can provide as much information as is available.

Message Edited by David_B on 04-04-2008 04:41 PM

[DrMike]

I'll upgrade to LV RT 8.5.1.  Can I assume it is going to be released with LV 8.5.1 on 4/14 (or there-abouts) or is it already out?

[David_B]

LabVIEW RT 8.5.1 is available as of 4/4/08.

I did notice something at second glance at the notes from R&D in the above mentioned CARs.  This has been addressed and fixed for strings, but has yet to be addressed for doubles.  You can simply convert from one to the other as needed to get past this.

Message Edited by David_B on 04-07-2008 11:04 AM