QA memory use / memory leak

[James R 5]

I have a QA which is using UDP to communicate with devices. Once the QA is initialised and all attributes collected the QA is regularly polling each device and receiving updated status. With no other activity I am seeing a large increase in memory usage of the QA over time, usually in small increments but occasionally big steps of 25%. After about a week the QA crashes or the HC3 locks up. I am now monitoring the memory, forcing the garbage collection regularly (which I shouldn't really need) and will restart the QA if usage goes above a certain level in order to protect the HC3. Not very elegant but it protects the HC3

 

I'm still relatively new to lua so I'm looking for any tips of where I should look to track down any issues. I have a core table with device information but this is not expanding over time. Are there things I could be doing in lua which create objects which cannot be recovered by the garbage collector?

[jgab 2,647]

So you are seeing what garbagecollect(...) returns increasing continously?

 

Of course your problem could be some table you increasingly grow, but your table(s) are is not expanding as you say.

Lots of setTimeouts/setIntervals will keep referenced data alive until they run.

 

Then we could expect the UDP. Each read/write has an asynchronous callback and data they reference will hang around until they complete...

 

Then there could be a leak in the UDP implementation - it depends on how they implemented it if it would show as Lua data usage.

Ex. in my QA emulator fibeEmu the net.* library is in Python and will now show in the Lua VM's memory usage. However, I expect the 

fibaro implementation is using the standard lua socket lib (even if it's wrapped as userdata)

 

[James R 5]

Yes, I am seeing a steady growth reporting out of garbagecollect. I did wonder if UDP was holding onto some data and I do have my main polling loop on a setInterval. The UDP does seem to complete all it's reads but there could be something underlying in the implementation. I could try closing the socket and reopening it after a period to see if that reduces the memory footprint. Thanks for the ideas.