AnsweredAssumed Answered

IMX8QMMEK Surround View App - Camera and application stability issues

Question asked by Mustafa Ozcelikors on Dec 17, 2018
Latest reply on Jan 29, 2019 by gusarambula
Branched to a new discussion

I am testing imx8 surround view application using a iMX8QMMEK. However, although the application and the image (fsl-imx-xwayland, fsl-imx-qt5-validation-image) are standard with the 4.9.51_beta2 BSP, I am having difficulties with the application. I am using the standard device tree with HDMI output enabled, that is fsl-imx8qmmek-hdmi.dtb.

I have already ran the Surround View application (Surround View Application|NXP ) with success, the application that NXP developed as a proof of concept for automotive developments.

 

However, looking into the code a bit, I think that the software contains a lot of memory leaks and is pretty error-prone. I think that because of the fact that I noticed a lot off unchecked pointer operations, unchecked system calls and returns, careless usage of thread locks that block you to send a termination signal in some cases, causing a deadlock in the application.

 

Let alone, it does not work every time you launch the application.

 

I plug my 4 cameras (1280x800) through a serializer and plug it in the imx8qmmek. However, the cameras get very hot after a couple of minutes. If you run the application for about 20 minutes, the application freezes. When you relaunch the application, this time cameras are not opened correctly (white display), with no error whatsoever in the application logs. Additionally sometimes I get ioctl `VIDIOC_G_PARM` failed. These issues are often solved after a reboot, for a while, until cameras decide to suddenly stop working again. I need some help regarding understanding why this happens, and how to solve it. Also, reproduction is pretty hard, as camera problem can occur even after a reboot sometimes.

 

To me there are two possible reasons:
1) The application does not clean up enough resources before exiting the application, or before each iteration.

2) Problems with the camera interface, driver or device-tree.

 

I'd appreciate if I could get some help regarding the aforementioned problems. Thank you very much in advance.

 

Additional: memcheck / valgrind summary after running for a few minutes:


$> valgrind --track-origins=yes --leak-check=full ~/App/Build/SV3D-1.1
==5061== HEAP SUMMARY:
==5061==     in use at exit: 455,157 bytes in 154 blocks
==5061==   total heap usage: 361,224 allocs, 361,070 frees, 189,148,035 bytes allocated
==5061==
==5061== 158 bytes in 2 blocks are definitely lost in loss record 2 of 9
==5061==    at 0x48452D0: realloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==5061==
==5061== 432 bytes in 6 blocks are definitely lost in loss record 3 of 9
==5061==    at 0x48450D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==5061==
==5061== 63,116 bytes in 2 blocks are possibly lost in loss record 8 of 9
==5061==    at 0x484304C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==5061==
==5061== 384,202 (382,692 direct, 1,510 indirect) bytes in 38 blocks are definitely lost in loss record 9 of 9
==5061==    at 0x484304C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==5061==
==5061== LEAK SUMMARY:
==5061==    definitely lost: 383,282 bytes in 46 blocks
==5061==    indirectly lost: 1,510 bytes in 56 blocks
==5061==      possibly lost: 63,116 bytes in 2 blocks
==5061==    still reachable: 7,249 bytes in 50 blocks
==5061==         suppressed: 0 bytes in 0 blocks
==5061== Reachable blocks (those to which a pointer was found) are not shown.
==5061== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5061==
==5061== For counts of detected and suppressed errors, rerun with: -v
==5061== ERROR SUMMARY: 4030008 errors from 651 contexts (suppressed: 0 from 0)

Outcomes