Eclipse Community Forums: 4DIAC - Framework for Distributed Industrial Automation and Control

Home » Eclipse Projects » 4DIAC - Framework for Distributed Industrial Automation and Control » Memory Leak Test(Does the FORTE source code validated with Memory leak Test?)

Memory Leak Test [message #1758775]

Sun, 02 April 2017 12:35

Eclipse User

I tried to run the FORTE (on Windows) source code with example provided in the below link:
https://msdn.microsoft.com/en-us/library/e5ewb1h3(vs.90).aspx

I found some memory leak information. Kindly provide your comments as I see memory increasing wheil running an application continuously for 2-3 days.

Note: My real usage was on Raspberry Pi 3, but I couldn't figure out how to detect memory leak on posix arch. So I used Windows here.

Attachment: ForteMemLeaksDump.txt
(Size: 4.20KB, Downloaded 169 times)

Re: Memory Leak Test [message #1758778 is a reply to message #1758775]

Sun, 02 April 2017 15:38

Eclipse User

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 #1758816 is a reply to message #1758778]

Mon, 03 April 2017 09:29

Eclipse User

Thank you for your reply.

I will take a look over the leak sanitzer. Regarding RASPI I am using wiringPi and pigpio library for IO control.

I tried to use VLD (Visual Leak Detector) for capturing more detailed information.

Hope this helps you.

Attachment: memory_leak_report_forte.txt
(Size: 63.29KB, Downloaded 153 times)

Re: Memory Leak Test [message #1758848 is a reply to message #1758816]

Mon, 03 April 2017 14:45

Eclipse User

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 #1758861 is a reply to message #1758848]

Mon, 03 April 2017 17:45

Eclipse User

On windows system I just closed console to collect the visual leak report. Because it provides report only when the application is closed.

On RASPI I saw the FORTE CPU memory usage gets increasing day-by-day and finally it hangs the Pi . Although there is an another process called Xorg was also increasing.

My test case here is just toggling 4 LEDs one after the other with 500mSec interval. I am using two RASPI with different addon boards which has same identical application running.

1) UniPi Board
2) PiXtend Board

Where as on UniPi I directly use pigpio library to control the Relay Output via I2C bus, but on PiXtend I have instruct the in-built microcontroller via SPI using wiringPi library to control the Relay Output.

Even though CPU memory increases on UniPi I haven't faced hanging issue on it. But on PiXtend it hangs the CPU and required a restart.

The same toggling logic without FORTE, i.e on a simple "C" code doesn't increase any CPU Memory.

I hope this helps.

Re: Memory Leak Test [message #1758926 is a reply to message #1758861]

Tue, 04 April 2017 12:17

Eclipse User

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 #1759105 is a reply to message #1758926]

Thu, 06 April 2017 09:19

Eclipse User

Hi,
I finally figured out the issue and found that I wasn't deleting a dynamically allocated memory inside the RASPI interface code.
While debugging I found few more interesting stuffs which I feel good to share or discuss.

I use many PUBLISH_x and SUBSCRIBE_x function blocks inside my application. While walking through the FORTE source code I understood that we have two communication layers that are used by these PUBLISH_x and SUBSCRIBE_x function block. At each function block instance an new "ipcomlayer" class get instantiated which intern creates "m_acRecvBuffer[cg_unIPLayerRecvBufferSize]" buffer and the variable cg_unIPLayerRecvBufferSize is an unsigned int cg_unIPLayerRecvBufferSize = 1500. Assuming 4 byte as sizeof unsigned int, then the actual size created is 1500x4byte = 6000byte.

Let us take if I need to send and receive only one BOOL data, aren't we making costlier memory for send just a single byte of data?

Kindly let me know, what happens if I provide INIT event frequently (by mistake) to these function block(s)

Re: Memory Leak Test [message #1759139 is a reply to message #1759105]

Thu, 06 April 2017 08:09

Eclipse User

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.

Previous Topic:	ModBus Protocol
Next Topic:	Modules and plug-ins

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Jul 26 13:49:17 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter