Problem with memory leak in modbus library

[samcat]

I am having a problem with a simple application that uses the Labview 2015 DSC Modbus library under windows 7.  My code reads out a number of registers from an  Orion nCompass MC i4.3 1 to 10 PID Loop Controller made by Future Design Controls which in turn controls a 3-zone power supply on a Thermcraft tube furnace.  Modbus via RS-232 is the protocol.  While the code apparently runs fine, after a period of days, the computer begins to slow way down eventually becoming unusable and requireing a re-boot.  The problem is that the simple application keeps using more and more memory until all page space is used up.  This is classic "memory leak" behavior.  Below is a plot memory usage made using Windows 7 Performance monitor to log pool non-paged space memory (I didn't let this run long enough to kill Windows).

I have also attached the VI that I used to perform this test.  Has there been any other experience with this problem?  Am I doing something wrong in my program that would cause this memory leak?

[samcat]

I'm replying to my own question.  I managed to work around this memory leak problem by using a different library of ModBus routines found at: http://www.ni.com/example/29756/en/ called NI MODBUS Library 1.2.1. This seems to be a simpler (perhaps less powerful?) set of routines that use normal VISA calls.  The above web page also mentions "a newer library, intended as a replacement" but I was unable to get past the e-mail confirmation rigmarole (it never sent the confirmation request e-mail to me) so I couldn't use the "newer library".  Despite the fact that I have solved my memory leak problem, it would be nice to find out if there is actually a bug in the official Modbus routines that come with the DSC add on.

[JB]

See here for the different Modbus libraries.

[Jacobson-ni]

I would be interested in seeing if you saw the same memory leak if you took the create and close functions out of the while loop and used the Set Unit ID function to iterate through your slave devices. I'm interested so I'll also see if I can see a similar memory growth by speeding up what you have here.

[samcat]

I didn't actually know about the "Set Unit ID function" (It's burried in the ModBus Master "utilities" menu).  I re-organized my test program to move the create and close functions out of the while loop and to use "Set Unit ID" to select the Unit ID instead of the "Create Modbus Master Instance" (the Unit ID has to be specified with the Create Modbus Master Instance, but I guess it can be anything -- I used 0 which isn't an ID in my system).  I've attached the modified test program.  After running this for a few days with Performance Monitor logging "Pool Nonpaged Memory (bytes)" as before I plotted that parameter vs. time of day:

As you can see, except for steps early in the morning of May 25 (Windows Update? Virus Scan?) the memory usage is basically constant.  So the suggested change stopped the continual increase in memory usage.  It still seems like either the "Create Modbus Master Instance" or the "Close Modbus Master Instance" is not properly releasing memory.

[Jacobson-ni]

Thank you for trying that out. I will ask around to see if this is a problem that others have run into. I tried testing this on my own computer but wasn't able to see any memory grown after a couple of hours and I was looping at ~10ms per iteration.

[Mrmas]

Hi,

I see this is an old tread, but I would just like to drop in and say I have seen the same or a similar problem with the modbus library. See my post in the modubs lab thread linked below (post 384 and 387). I see the same issue with the Real-time modbus library and the labview labs library, a growing memory use both on the master and the slave side with rapid reconnecting modbus masters, I have posted example code.. 

http://forums.ni.com/t5/forums/v3_1/forumtopicpage/board-id/7124/thread-id/10/page/39

I also contacted support and I think now there is supposed to be a CAR open for it ( CAR:617407), but I can never find a list of active CARs.

Regards

Mrmas 

[Jacobson-ni]

---

@Mrmas wrote:

I also contacted support and I think now there is supposed to be a CAR open for it ( CAR:617407), but I can never find a list of active CARs. 

---

You won't be able to find a list of active CARs, you will have to check the bug fix list with every realease to see if it has been fixed. Because I was the AE that looked into this and all the VIs I found that need to be fixed are open I figure it would be good to share that information. I'm not saying this will fix all issues everyone is seeing but it was a problem we found that did lead to memory leaks when you are constantly connecting and disconnecting from a network.

From my testing, I could not find problems with disconnecting and connecting from a network with LabVIEW as a master. I ran a test for a couple of days on a cRIO that connected, read a register and coil, and disconnected to a slave device ~2 million times and didn't see the memory change. I did, however, find an issue with the slave API. The problem I did find had to deal with how the TCP slave daemon stores new connection information. If you look into the Wait on Connection case in TCP Daemon.vi, for every accepted TCP connection we create a DVR for basic status information, launch a connection handler, and add that DVR to an array of connection lists. The problem seems to come from the Remove Unused Connections.vi shown below.

This VI runs after a new connection is created and the specific case shown above will go through and remove inactive connections from the record if the record list gets too large. Unfortunately, this does not close the DVR if it is not passed through the conditional index, and because I couldn't find anywhere else this would be closed, the DVR we no longer keep track of is floating in the ether taking up more and more memory. 

From the tests I did in DETT, establishing >50 connections and then closing the Slave instance will show memory leaks for each additional connection opened. When I changed the above VI to close the DVR when Connected? is false I no longer saw memory increases or memory leaks from new connections. Not to say they aren't there, but my simple tests didn't show anything.

I hope this helps someone else running into this particular issue.

[Mrmas]

Thank you very much Jacobson, that does seem like the problem.

Could i ask how this should best be fixed? I am not very used to DVRs. I guess i could add a delete data value referance to all referanses that show "connected?" as false?

Also how would i best add such a fix to the standard library without making it hard to use with other versions of labivew or similar.

Is this an issue only with the TCP slaves then? i dont need to change anything for the serial slave?

Thanks again, 

Mrmas

[Jacobson-ni]

I did exactly what you suggested by deleting the DVR in that false case and it seemed to work for me. Running a DETT trace after making that change got rid of all the memory leaks I was seeing. I can't be completely sure that it won't have any unintended behavior but it only looks like that connection status is set to false when the specific instance of the connection manager closes out. Additionally, the only other place I could find that DVRs were closed was at the API's close call which just takes the list of connections and closes everything.

For development, if you didn't want to change vi.lib, you could create a source distribution and replace all Modbus calls you make with VIs from that distribution. Then if you fix that source distribution it would carry over with the rest of your project. You'll just have to be careful that when you go to add more Modbus functionality to use the VIs from the source distribution instead of the pallettes.

Also, I didn't do testing for the serial connection but the daemon is handled very differently and doesn't use DVRs so if it does happen to leak memory it would be a very different issue.