TDA4VM: EGLDisplay memory leak.

Hello Li,

Could you give me a few days to reproduce the error? If there is an example binary that you are willing to share that exhibits the error, that will also be great.

Please expect a reply by Wednesday of next week.

Regards,

Takuma

Hello Takuma,

The above code can be run by pasting it to main.cpp.

Regards,

Li

Hi Li,

I have attempted to reproduce the memory leak using the code snippet, but I have not been able to reproduce the issue yet. Could you confirm that you are still able to see the memory leak using the code snippet shared?

Also, I noticed that you have 2 displays defined:

1. "mDisplay" is initialized and terminated
2. "eglDisplay" is made the current context

For my tests, I have made these all the same name. Is this correct?

Regards,

Takuma

Hello Takuma,

1.Sorry, eglDisplay == mDisplay.

2. Memory leaks still exist.

3. After the following code loops 200 times, you can see this by looking at the process memory.

=====================================================================================

Hello Takuma,

==227444== 26 bytes in 1 blocks are definitely lost in loss record 6 of 220
==227444== at 0x4865788: malloc (vg_replace_malloc.c:381)
==227444== by 0xD88C5DB: ??? (in /usr/lib/libglslcompiler.so.1.10.5371573)
==227444== by 0xD8190D3: ??? (in /usr/lib/libglslcompiler.so.1.10.5371573)
==227444== by 0xD83C44F: ??? (in /usr/lib/libglslcompiler.so.1.10.5371573)
==227444== by 0xD879C77: GLSLCompileToUniflex (in /usr/lib/libglslcompiler.so.1.10.5371573)
==227444== by 0xD47C063: ??? (in /usr/lib/libGLESv2_PVR_MESA.so.1.10.5371573)
==227444== by 0xD48298F: ??? (in /usr/lib/libGLESv2_PVR_MESA.so.1.10.5371573)
==227444== by 0xD4843D7: ??? (in /usr/lib/libGLESv2_PVR_MESA.so.1.10.5371573)
==227444== by 0xD487D77: ??? (in /usr/lib/libGLESv2_PVR_MESA.so.1.10.5371573)
==227444== by 0xD2CF903: ??? (in /usr/lib/libsrv_um.so.1.10.5371573)
==227444== by 0x4D9780F: start_thread (in /usr/lib/libpthread-2.30.so)
==227444== by 0x701AB5B: ??? (in /usr/lib/libc-2.30.so)
==227444==
==227444== 12,321 (48 direct, 12,273 indirect) bytes in 1 blocks are definitely lost in loss record 220 of 220
==227444== at 0x4865788: malloc (vg_replace_malloc.c:381)
==227444== by 0xD1B86D3: ???
==227444== by 0xD1B86AF: ???
==227444== by 0xD1B6C5B: ???
==227444== by 0xD1B6F9B: ???
==227444== by 0xD1B5F6B: ???
==227444== by 0xD1B6B07: ???
==227444== by 0x400DD53: call_init.part.0 (in /usr/lib/ld-2.30.so)
==227444== by 0x400DE53: _dl_init (in /usr/lib/ld-2.30.so)
==227444== by 0x4011AC7: dl_open_worker (in /usr/lib/ld-2.30.so)
==227444== by 0x7050413: _dl_catch_exception (in /usr/lib/libc-2.30.so)
==227444== by 0x4011413: _dl_open (in /usr/lib/ld-2.30.so)
==227444== by 0x70F0FCB: ??? (in /usr/lib/libdl-2.30.so)
==227444== by 0x7050413: _dl_catch_exception (in /usr/lib/libc-2.30.so)
==227444== by 0x705048B: _dl_catch_error (in /usr/lib/libc-2.30.so)
==227444== by 0x70F1677: ??? (in /usr/lib/libdl-2.30.so)
==227444== by 0x70F1053: dlopen (in /usr/lib/libdl-2.30.so)
==227444== by 0x4BC0B5B: ??? (in /usr/lib/libEGL.so.1)
==227444== by 0x4BC0D1F: ??? (in /usr/lib/libEGL.so.1)
==227444== by 0x4BCE1CB: ??? (in /usr/lib/libEGL.so.1)
==227444== by 0x4BCE2BF: ??? (in /usr/lib/libEGL.so.1)
==227444== by 0x4BC1873: ??? (in /usr/lib/libEGL.so.1)
==227444== by 0x4BBCBAB: ??? (in /usr/lib/libEGL.so.1)
==227444== by 0x4BBCC03: ??? (in /usr/lib/libEGL.so.1)
==227444== by 0x4BB1A23: eglInitialize (in /usr/lib/libEGL.so.1)
==227444== by 0x493CA5F: ATDA4::init(void*, void*) (in /opt/cache/avm/output/lib/libbaidu_avm_engine.so)
==227444== by 0x493CD7F: AEGL::create(void*, void*) (in /opt/cache/avm/output/lib/libbaidu_avm_engine.so)
==227444== by 0x493F067: AVMEngine::init(baidu_avm_engine::ABasisData&, baidu::pavaro::avm::RenderEventListener*) (in /opt/cache/avm/output/lib/libbaidu_avm_engine.so)
==227444== by 0x41D97F: main (main.cpp:188)
==227444==
==227444== LEAK SUMMARY:
==227444== definitely lost: 152 bytes in 5 blocks
==227444== indirectly lost: 12,273 bytes in 183 blocks
==227444== possibly lost: 0 bytes in 0 blocks
==227444== still reachable: 19,255 bytes in 105 blocks
==227444== suppressed: 0 bytes in 0 blocks
==227444== Reachable blocks (those to which a pointer was found) are not shown.
==227444== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==227444==
==227444== For lists of detected and suppressed errors, rerun with: -s
==227444== ERROR SUMMARY: 36705 errors from 1005 contexts (suppressed: 0 from 0)

Regards,

Li

Hi Li,

I did a test that loops through your code snippet 200 times using PSDK Linux 7.2 and the latest 8.2 release, and the latest 8.2 release seems to be more stable compared to 7.2.

Could you also do the tests on the 8.2 release on your side to confirm?

The following is the result from valgrind running the same code:

For 7.2: 

==1120== HEAP SUMMARY:
==1120==     in use at exit: 2,476,651 bytes in 37,204 blocks
==1120==   total heap usage: 201,411 allocs, 164,207 frees, 76,518,070 bytes allocated
==1120==
==1120== LEAK SUMMARY:
==1120==    definitely lost: 28,141 bytes in 599 blocks
==1120==    indirectly lost: 2,447,043 bytes in 36,600 blocks
==1120==      possibly lost: 0 bytes in 0 blocks
==1120==    still reachable: 1,467 bytes in 5 blocks
==1120==         suppressed: 0 bytes in 0 blocks
==1120== Rerun with --leak-check=full to see details of leaked memory
==1120==
==1120== Use --track-origins=yes to see where uninitialised values come from
==1120== For lists of detected and suppressed errors, rerun with: -s
==1120== ERROR SUMMARY: 9207456 errors from 717 contexts (suppressed: 2006276 from 187)
root@j7-evm:~#

For 8.2:

==1482== HEAP SUMMARY:
==1482==     in use at exit: 1,451 bytes in 4 blocks
==1482==   total heap usage: 254,819 allocs, 254,815 frees, 142,973,478 bytes allocated
==1482==
==1482== LEAK SUMMARY:
==1482==    definitely lost: 0 bytes in 0 blocks
==1482==    indirectly lost: 0 bytes in 0 blocks
==1482==      possibly lost: 0 bytes in 0 blocks
==1482==    still reachable: 1,451 bytes in 4 blocks
==1482==         suppressed: 0 bytes in 0 blocks
==1482== Rerun with --leak-check=full to see details of leaked memory
==1482==
==1482== Use --track-origins=yes to see where uninitialised values come from
==1482== For lists of detected and suppressed errors, rerun with: -s
==1482== ERROR SUMMARY: 9904906 errors from 695 contexts (suppressed: 2004975 from 189)
root@j7-evm:~#

Also, does valgrind print a lot of errors before entering the main function on your set up? 

Regards,

Takuma

Hello Takuma,

Our company's products have been mass-produced. Can you provide a patch ?

Regards,

Li

Hi Li,

We have ran some experiments and found a newer version of the GPU firmware that is compatible with SDK 7.2 and valgrind does not report memory leak.

Could you try updating the GPU firmware to the 1.13 version using a procedure similar to: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1094811/faq-tda4vm-how-do-i-update-the-gpu-driver-to-a-newer-version

Please note: The instructions I linked are for SDK 8.2, so you would have to change the directory names to match the folder names in SDK 7.2. Additionally, you will need to checkout 1.13-5776728/linux-k5.4 for the driver and linuxws/dunfell/k5.4/1.13.5776728 branche for the umlib.

Regards,

Takuma

Hello Takuma,

We have tested SDK 7.3 so far and there is no memory leak. We will test SDK 8.2 later.

Regards,

Li

Hello Takuma,

Ok, thank you very much. 

Regards,

Li