UDP memory leaks/lakes?

[kentv]

I am wondering if anyone has had any issues with memory leaks/lakes when using UDP and data queues? 

The program has a section of code where queues are loaded with data read from various UDP ports. The queues are then read by a loop (which is triggered by a 1kHz timing source) and some of the data is displayed on the front panel of the main VI. When the program is running it leaks memory at about 100kbps leading to a failure in about 4-5 hours when the physical RAM is maxed out. 

I think I have traced the issue (using the DETT it shows many memory allocation operations) to the subVI I have attached that fills the queues. Can anyone help point out any thing that might be leading to the memory leaks/lakes?

Thanks!

[johnsold · Accepted solution]

I suspect the issue is that you are not emptying the queues fast enough. And that is not in the code you posted. It is also missing some subVIs, classes, and controls.

Generally timed loops should only be used on real time operating systems. They offer no advantages over the standard while loop and have some additional overhead when operating on a desktop OS. Also placing indicators inside fast loops can create issues. The OS only updates the screen some tens of times per second, so writing to indicators 1000 times per second forces LV or the OS or both to manipulate the data.

Having multple timing methods in one loop can lead to problems.  The UDP timeout is likely based on the tick count clock. If you have the UPD Read timeout set to anything greater than zero, the UDP Reads may take longer than the timed loop interval.  Use the UDP Read timeout to put some wait into a standard while loop.

Lynn

[Dave_Brandt · Accepted solution]

Are you dequeing all elements in your ques? Do you have a size limit for your ques? How reliable is your udp producers? I usually have my udp read blocks in a separate loop for each producer and set my loop time to zero and then set a reasonable udp timeout (250 msec) .This way if you have a network delay it will process any backlogged udp packets but waits for the udp sender a reasonable time.  You would need to filter out time outs. If this is not on an isolated network I also suggest using the ip address of the sender as a condition input for the case structure. Any one sending to your port and broadcasting could add data that is in the wrong format for your Que. 

[kentv]

---

@johnsold wrote:

I suspect the issue is that you are not emptying the queues fast enough. And that is not in the code you posted. It is also missing some subVIs, classes, and controls.

Generally timed loops should only be used on real time operating systems. They offer no advantages over the standard while loop and have some additional overhead when operating on a desktop OS. Also placing indicators inside fast loops can create issues. The OS only updates the screen some tens of times per second, so writing to indicators 1000 times per second forces LV or the OS or both to manipulate the data.

Having multple timing methods in one loop can lead to problems.  The UDP timeout is likely based on the tick count clock. If you have the UPD Read timeout set to anything greater than zero, the UDP Reads may take longer than the timed loop interval.  Use the UDP Read timeout to put some wait into a standard while loop.

Lynn

---

I imagine you are right about the emptying of the queues. The program is quite large so it's hard to post the portion that reads the queues, however I am going to put the Get Queue Status VI on the queues and check to see if they are always increasing. The incoming UDP data is from a real-time system which sends it out 500 times/sec. Maybe I will need to lower that to ensure the queue empties. I'll post an update on what the Get Queue Status shows.

[kentv]

I said I'd post an update after inserting Get Queue Status and here it is. One of the queues was filling up continuously and not emptying. After looking through the existing code, I found that the queue was never being dequed or even being used for that matter. As a result I just deleted the queue and don't listen to that UDP port anymore.

The result is much more stable memory.

Thanks for the posts and assistance!