Skip to content

System memory overflow in SAM9X60_Curiosity when using EGT #31

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ZarathElgin opened this issue Mar 13, 2025 · 8 comments
Closed

System memory overflow in SAM9X60_Curiosity when using EGT #31

ZarathElgin opened this issue Mar 13, 2025 · 8 comments

Comments

@ZarathElgin
Copy link

We used the SAM9X60_curiosity kit.

In the example snippet below, we displayed an image (png) for 2 seconds and then replaced it with another.
#include <egt/ui>
#include <egt/widget.h>
#include <egt/label.h>
void DisplayController::ShowPicture(int figure)
{
string path;
switch (figure)
{
case 1:
path = "root\images\Picture1.png";
break;
case 3:
path = "root\images\Picture2.png";
break;
case 3:
path = "root\images\Picture3.png";
break;
case 4:
path = "root\images\Picture4.png";
break;
case 5:
path = "root\images\Picture5.png";
break;
}
imagemBackground->image(egt::Image(path));
thisWindow.damage();
thisWindow.show();
resetTimer.change_duration(std::chrono::milliseconds(2000));
resetTimer.start();
}

This work with excellent image quality and no flickering on the screen, but after displaying each image, system memory consumption increases.
If we display about 30 images, Linux crashes due to lack of memory (this can be seen by the command "free -h"

What is the method to deallocate an image from memory after displaying it?

@ldesroches
Copy link
Contributor

Hi,

Could you try to track the memory usage of you process, with a tool such as top. We are aware of a memory leak in the kernel driver of the LCD controller. I'm wondering if it can be the cause of your memory leak. If the memory of your process, doesn't increase, check /proc/meminfo to see where there is a significant increase of the memory. Then I could confirm if it comes from the driver of the LCD controller.

Regards,
Ludovic

@ZarathElgin
Copy link
Author

Hello Ludovic,

Thanks for your help.
Please see the attached file about memory values:
Memory_Consumption.pdf

Is there any other way to display multiple images (with or without "EGT") without increasing memory consumption?

Thanks again.

Regards.

@ldesroches
Copy link
Contributor

Hello,

From what I see, the driver doesn't seem to be involved in the memory leak. So something is wrong in the application or EGT.

Can you provide a code snippet to reproduce it. There is not enough context with the code you shared to let me understand how you did. Which version of EGT are you using.

Regards,
Ludovic

@ZarathElgin
Copy link
Author

Hi Ludovic,

Thank you for your help.

The Linux version is:
Linux sam9x60curiosity 6.6.23-linux4microchip-2024.04 #2 Fri Jan 31 14:17:32 -03 2025 armv5tejl GNU/Linux

We couldn't get the EGT version (how do I get it?).
Anyway, we used this one:
git clone --recursive https://github.com/linux4sam/egt.git

Below is a complete example code and also the project.

Start code:
#include <egt/ui>
#include <egt/uiloader.h>
#include <egt/widget.h>
#include <egt/label.h>
#include <egt/video.h>
#include
#include
#include <egt/image.h>
#include
#include

static std::string getWorkDir()
{
char cwd[PATH_MAX];
if (getcwd(cwd, sizeof(cwd)) != nullptr)
return std::string(cwd);
else
return "";
}

int main(int argc, char** argv)
{
egt::Application app(argc, argv);
egt::TopWindow window;

std::string workingDir = getWorkDir();
std::vector<std::string> imagePaths = {
	"file:" + workingDir + "/img01.png",
	"file:" + workingDir + "/img02.png",
	"file:" + workingDir + "/img03.png",
	"file:" + workingDir + "/img04.png",
	"file:" + workingDir + "/img05.png",
	"file:" + workingDir + "/img06.png",
	"file:" + workingDir + "/img07.png",
	"file:" + workingDir + "/img08.png",
	"file:" + workingDir + "/img09.png",
	"file:" + workingDir + "/img10.png"
};

auto image = std::make_shared<egt::ImageLabel>(egt::Image{imagePaths[0]});
egt::center(image);
window.add(image);
window.show();
int index = 0;
egt::PeriodicTimer timer(std::chrono::seconds(2));
timer.on_timeout([&]()
{
	index = (index + 1) % imagePaths.size();
	image->image(egt::Image{imagePaths[index]});
});
timer.start();
return app.run();

}
End code

Complete code:
ExampleFor_SAM9X60_Curiosity.zip

In the example an image will be shown every 2 seconds, and then the next image will be shown.
Each image displayed is allocated in the board's memory.
When the last image is shown, the size of the consumed/free memory stabilizes, since all the images have been shown.
However, our application will display dozens of different images (at an interval of 2 seconds per imagem) causing there to be no memory available in the system.

Thanks again.

Regards.

@ldesroches
Copy link
Contributor

ldesroches commented Mar 18, 2025

Hi Zarath,

To get the EGT version, you have to set the EGT_DEBUG environment variable. 2 is enough to get info messages. If you have compiled EGT with debug enable, you can set it to 1. Then you get debug messages.

From what I observed with the code you provided, there is no memory leak. I let the app run several minutes and the memory usage doesn't change.
I think you are observing the image cache mechanism. When an image is loaded for the first time, it is stored in a cache. The goal is to load the image faster if we need it several times. Of course, the price is a higher memory usage. With the debug messages, you can see the cache miss causing the loading of the image in memory.

If you don't want this mechanism, you can clear the cache after each image you load:

`
#include <egt/detail/imagecache.h>

[...]

image->image(egt::Image{imagePaths[index]});
egt::detail::image_cache().clear();

[...]

`

Doing this, I don't observe an increase of the memory usage. Let me know if it fixes the issue on your side as well.

Regards,

Ludovic

@ZarathElgin
Copy link
Author

Hi Ludovic,

The solution you proposed worked perfectly, making a significant difference in the progress of our work.
We tested it for several hours, and the cache memory remained stable, with no freezing issues due to a lack of memory.

We would like to kindly request a link to a website where we can access the complete EGT documentation.
If there are any specific recommendations or additional materials that could assist us, we would greatly appreciate the suggestion.

Once again, thank you very much! Your help has been extremely valuable.

Best regards,

@ldesroches
Copy link
Contributor

Hi Zarath,

That's great.

Here is the EGT documentation, but you probably already know it: https://linux4sam.github.io/egt-docs/index.html
It's more an API doc than a documentation about the internal of EGT. The image cache mechanism is not explained, for instance. I agree that it's the lack. We try to improve it when introducing new features, but there are still legacy features not described.

Regards,
Ludovic

@ZarathElgin
Copy link
Author

Hi Ludovic,

Once again, thank you very much!

Regards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants