Memory Leak on AM33X and WinCE 7 related to screen refreshing

All,

I've just found a #define DEBUG_NEON_MEMORY_LEAK and I was wondering if it has anything to do with the issue I'm trying to find...

Please let me know if you have any ideas.

Thank You!

Zack

Dear Developer

Considering this is not happening on the EVM, I request you for the following information:

1. what is the difference in the display compared to EVM?

2. have you adapted the display and verified all adaptation matches to the expected changes? For example, if the resolution is different, it could be that memory mapping is getting messed up due to different size of display buffer being mapped (in config.bib).

Considering we are discussing custom hardware, it is challenging to discuss your schematics and custom BSP without NDA but we leave it to you to decide how far you want to go into details. We will support you accordingly.

Zack,

It might also be helpful to know if it's leaking virtual or physical memory, or both.

What is the amount of memory leaked, and how do you determine that there is a leak in the first place?

Is the leaked memory allocated in AllocSurface? (sorry this is not entirely clear to me from the description).

Best regards,
Carsten

Adeneo Embedded support team,

Thank  you for your response.

1. Yes, the new display is different than the one from the EVM board - it has a different resolution (480 x 272 vs 800 x 480 on EVM). 

2. I've made some additional tests yesterday. I've changed the display resolution for the EVM board build to 480 x 272 and all the mamory layout in config.bib to match our board's settings - and there is still no leak.  In this case ine smaller part of the display is being used. The right side of the display is black and - what is interesting - the bottom part (below the active area - in rectangle (x,y,w,h): 0,272,480,208) shows a copy of the area from 0,0,480,272. Anyway, there is still no leak on the EVM.

Also, I've changed our custom board's all the LCD settings (timings, etc., except the resolution, which is still 480 x 272) to match the EVM board.  The picture is not clear with that, but there is still a memory leak. 

So at this point all the code and settings related to the display are the same on both devices, and there is still a leak on our board and no leak on the evm.

Best regards,

Zack

Carsten,

Thank you for your response.

I know it's leaking virtual memory and since it's mapped to the physical memory, I suspect it's leaking the physical memory too, but I haven't really checked that by accessing the memory directly.

The amount of memory depends on the screen upddating rate. I'm testing it with a Task Manager written by us - which shows the memory allocated and used per process and I can see the numbers growing there. Then, since we update the screen to show the numbers, we have a new leak and the numbers change again. With that application running, I can see the leak about 2 KB per second.

I still don't know if the leaked memory is allocated in AllocSurface. I suspect that, but I'm not sure.

Thank you,

Zack

Hi Zack,

Just trying to narrow down where the issue might be.

Virtual memory (or virtual address space) is not necessarily mapped to physical memory - it might just be a device (such as the graphics controller or particular set of registers) mapped into memory, which is why it might be useful to know whether physical memory is leaking at the same rate. If it is not, then you could limit your search to VirtualAlloc/Copy calls and the like. You can call GlobalMemoryStatus() to determine the amount of available physical memory, or you can use one of the remote tools in Platform Builder to track memory usage.

Also - just to rule out any issues with the Task Manager - do you see the leak when running other applications? Could you rewrite the Task Manager to just dump the values to the console or to debut output.

Carsten,

Yes, you're right - it may be mapped to a device. That's a good point actually. Somehow I assumed it has to be a problem with virtual memory mapped to a physical memory since we have a region in RAM that is used for video purposes, but - you're right - it doesn't have to be that. I'll analyze that.

For Remote Tools, I had some problems with connection initially - that's why I started from analyzing and comparing the code, but I'll have to solve the connection problem (it's probably very simple) and use i.e. Remote Heap Walker to see all the allocations made. Thank you for pointing that.

For the Task Manager - it's not a source of the problem. Yes, I can see the leak when running other applications - even with moving/swtching Windows Explorer windows. Also, the same Task Manager runs without any leak on several other platforms, even on the EVM board.

Thank you for pointing me to all the options I have!

I'll let you know how it goes.

Best regards,

Zack

OK, I found the leak and we have a temporary solution.

First, I found a pretty useful tool, which is under Platform Builder: DevHealth. You can see the heap usage per process and per module at a certain time. This is a command line tool running on the device and it can be set to create a dump file every 15 minutes and then compare the results. With that I was able to confirm that the leak comes from the display driver.

However, there is over 10 lib files that are linked to the display driver dll. Several of them are PowerVR dlls and are linked only if PowerVR is enabled. So I've disabled it and the leak disapeared.

Since we don't need the PowerVR in the OS build, we can use the OS without it for now and I'll continue working on the problem to understand it completely. Probably some memory settings are not right for PowerVR (i.e. not enough memory declared in config.bib).

Carsten, thank you again for your help!

Best regards,

Zack