Hi all,
I am having a memory consumption issue with the ConnectPort X4 running Dia that I need help with.
When I boot the ConnectPort X4 at the start of the day, I have 1707 KB free memory. After several hours (overnight), I only have 30KB available and ,of course, the unit is not very responsive. If I reboot, I go back to 1707 KB free memory. The log file does not show anything unusual.
What is consuming the memory and how do I prevent the problem without having to reboot every day?
Some background info:
I have a ConnectPort X4 with a BL4S100 running the gpio_Server_C application.
BL4S100 - Only 1 Analog input and 1 Digital output compiled in and reporting
(1) Digi Bridge Router - Temp / Light sensor
(1) Digi Battery powered Light Temp sensor
NTP Time server on the X4.
The ConnectPort X4 is set to poll the BL4S100 once every 5 seconds. The two sensors push data up every 5 seconds
The NTP server updates the time once a day.
Sorry for the delay in looking at this. I’ve recently pulled up your configuration and would like a few more details so that we can hopefully find whatever is going on.
First of all, I hope you’re still active and having some success with your BL4S100, if you’ve resolved the issue that would be wonderful. Please let me know if that happens to be the case.
However, I don’t recall seeing anything here on the forum about that, so perhaps you can help me out. I’ve got your dia.yml, I know you’re running 1.1.15 against a BL4S100 dev board. You mention that you’re running a gpio_Server_C application. Is this an app of your own? I do not see this as being one of the applications distributed with the Add-on kit. If you don’t mind, in order to ensure that we’re on the same page, would you mind sharing this code or clarifying which application is loaded?
Thanks,
Is there any workaround other than rebooting? Or is there a specific function that I should avoid to prolong the uptime until the firmware fix is available?
The leak is a small leak that happens each time that the gateway does a DNS lookup. The best workaround right now would probably be to replace lookups that occur often with the IP address of the host being contacted.
The most common place where we have seen this be an issue is in devices configured for remote management through iDigi. If you have a domain name configured for the server address and are using the cwm_data presentation in Dia, the server address will be looked up each refresh interval.
That would be great. Although changing the Domain names to IP addresses helped a lot, I am still losing a little memory when I check every hour or so.I will still have to reboot every few days or so to keep up the amount of free memory.
Okay, the fixed firmwares are up (or going up) on the support.digi.com site now. You need:
X2 = 82001596_E2.bin
X2-WiFi = 82001630_E1.bin
X4 = 82001536_E3.bin
X8 = 82001115_F2.bin
They should be dated August-24-2009 (or 25th). If dated March or May 2009, those are older.
The cellular products also have new images, but I won’t list all of those. The memory issue only is seen with code using DNS name lookup - so a cellular customer putting a DNS name in Surelink or other settings will cause the problem.
Did not seem to fix the problem. I have a ConnectPort X4 and loaded the new firmware dated 8/24/2009. I rebooted and started at 1.5M and after 19 hours I was down to 79KB:
CPU Utilization: 13%
Up Time: 19 hours 8 minutes 36 seconds
Date and Time: Sat Aug 29 16:30:30 2009
Total Memory: 16384 KB
Used Memory: 16305 KB
Free Memory: 79 KB
The only thing running on the X4 is Dia configured as detailed in the previous post. I also left all of the URLs with hardwired IP addresses. Any additional data I can provide to diagnose the problem?
Something else is going on then - the E3 fixed my own Dia issues superbly, plus I’ve heard from several other people with no problem now on X4 or X8.
Sounds to me like an infinitely growing data object then, which is easy to do in Python since even strings can be millions of bytes long. I don’t have any BL4S100 and have never tried the gpio_Server_C application. You could try uploading your YML file to the forum.
Since the X4 firmware solved my memory problems & I don’t have any of your hardware, it rather dampens my interest.
You should look for any python code which does an “append” or “extend” of a collection object like a list, especially if you use things like “mylist[-1]” to access that list from the end. A “+=” is also something to watch.
I have witnessed several cases where programmers use a list as a queue, but have a logic error which never “pops” the earlier data off and the queue grows forever, eating all memory.
Most of my Dia drivers exist as 2 files - the 1st is 100% stand-alone and a simple linear process object (you call, pass inputs and receive outputs). This I can unit test alone on a PC extensively. The 2nd is the Dia driver glue which can only be tested within a running Dia given the timing/thread constraints of Dia.
Thanks for the follow up - I still have the problem, I just got busy and decided to reboot the gateway every day as a workaround.
The gpioserver C code is the Dynamic “C” code that gets loaded into the BL4S100. It is part of the library that gets downloaded with compiler. I did not change that code, just loaded it into the Bl4S100 with the USB cable.
The DIA code that runs in the CX4 to support the BL4S100 is the gpio.yml and is in the standard DIA 1.1.17 package. When you extract the package, the file is in the following directory:
DIA\demos\rabbit\gpio.yml
I did not modify the source code, I just configured the YML to create the channels coming in from the BL4S100 using the gpio.yml as a model. See my earlier upload of the YML file that gets loaded onto the CX4 for my running configuration.
Sorry if I did not explain that very well and confused you.
Thanks for getting back to me. Over the last couple days I have been running as close as I can achieve to what I believe to be a version of your environment. I am unable to observe the memory loss that you are observing.
If you’re inclined, one of the things that you could do that would restrict the scope of things to investigate would be to create a YML file that represents the minimal configuration necessary to reproduce the problem. I suspect that the problem lies in the XBeeGPIOClient code, so that’s probably where I would recommend starting. Turning off all other drivers and presentations and observing the system for a continued leak would be helpful.
I don’t believe it is a presentation, but turning those off as well would probably be useful. If you want one on to continue to be able to monitor channel data, I would suggest adding an entry for the console presentation. That does not perform periodic activity and is only driven by requests from a user, so could not contribute to any leaking configuration.
Thanks for your cooperation. Please post as an attachment the resulting YML file if you’re able to do this.