This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Part Number: AM5729
Like the title says, I have a BeagleBone AI running the latest (as of writing) [Debian Buster image](https://beagleboard.org/latest-images). It seems there is a memory handling issue when I try to run the openCL examples found under `/usr/share/ti/examples/opencl`. See the attached valgrind output.
Is this a known issue, or is this something I need to take up with the BeagleBone folks?
Debian is not supported by TI. Please contact the Debian community on www.beagleboard.org
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Biser Gatchev-XID:
My apologies - thanks for the suggestion.
I've been advised to try using the TI Processor SDK image (v06.02) on an SD card, but I'm still getting memory leaks running the same example. See attached.
EDIT: I should mention that I have not been successful in using v06.03 on an SD card.
In reply to Matt Anderson:
I was finally able to load the v6.03 SDK onto an SD card and try again, and I get the same memory leak as in v6.02. Attached.
We took a look into your valgrind report:
==1299== possibly lost: 961,415 bytes in 1 blocksThis is from libelf. We did call elf_end() and it did return 0, which means the resources should have been released by libelf. Valgrind did report "possibily." Even if it is not released, the corresponding function is called only once and the memory is one-time allocation per process.
==1299== still reachable: 796 bytes in 11 blocksThese are from various underlying libraries that OpenCL host runtime depends on. For example, inter-processor communication library. These memories are only allocated once per process and they will be deallocated when process terminates. In other words, it doesn’t matter if you run your kernel 100 times or 100 million times, these memory allocations will not change.
The summary is there should be no concerns here. A "concerning" memory leak would be that the runtime is allocating more and more new memory for the same use, while not releasing old memory as program runs longer and longer. This is not the case for the warnings that are flagged.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.