|
Re: Memory Leak Test [message #1758778 is a reply to message #1758775] |
Sun, 02 April 2017 19:38 |
|
Thank a lot for bringing this to our attention. Unfortunately from the dump given I don_'t see where this memory was allocated. Do you have more information on this? How did you end FORTE?
There are options to directly test this also on the RASPI, which would be more interesting I guess. For gcc there are so called sanitzers which you can enable for the forte build and should provide you feedback on such issues. In the dev docu of FORTE I provided a startpoint. I think for you the leak sanitzer and the adress sanitzer would be the most interesting. However these require gcc > 5.1.
May I also ask if you are using special libraries with FORTE or a plain FORTE. Because this is the first time that we here that FORTE has memory leak issues.
|
|
|
|
Re: Memory Leak Test [message #1758848 is a reply to message #1758816] |
Mon, 03 April 2017 18:45 |
|
Thanks for the new leak report. This helps to better understand the last report. May I ask how you shut down FORTE? Because it looks like that FORTE has not been cleanly shut down. But even if we are have here a clean-up issue the memory it shows is allocated once during startup. So it would not explain why you see issues after 2-3 days.
|
|
|
|
Re: Memory Leak Test [message #1758926 is a reply to message #1758861] |
Tue, 04 April 2017 16:17 |
|
Ah ok. This explains the memory issues as when just closing the terminal I would expect that FORTE is not correctly shutdown. You can shut down forte by sending a kill device command from 4diac-ide (right click on a device) or by hiting ctrl+c in the terminal (not sure if this fully works in windows).
May I have a look on your code which interfaces between wiringPi, pigpio and 4diac? I would assume that somewhere there the issue could hide. You could also test this with a simple FORTE application with no I/O FBs and see how the memory is behaving there.
|
|
|
|
Re: Memory Leak Test [message #1759139 is a reply to message #1759105] |
Thu, 06 April 2017 12:09 |
|
Great that you found your issues.
Yes you are right we are currently using a little to much memory especially when using the raw IP layer. The situation is definitely better with other protocols (e.g. MQTT or OPC UA). The main problem is that I currently don't know a good means for determining the size of the UDP or TCP packet which was received. Having that would allow us to greatly reduce this buffer and optimize it for the real needs.
If more INIT events are coming the CComFB sees that the FB is already initialized and will do nothing. Only if you switch your QI to false then it will deinitialize the FB resulting in deleting the whole stack of CommLayers adn freeing up all the memory.
|
|
|
Powered by
FUDForum. Page generated in 0.03432 seconds