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.

TDA4VM: TIVOX

Part Number: TDA4VM

Tool/software:

Hi,

[background]
- TI SDK version: 8.2, QNX
- The Question is related with TIOVX and shared memory allocator.
We have got an issue which is hard to reproduce (<5%): the pipeline of surround camera view has encountered a memory failure, which resulted in a black screen issue from vehicle market. details:
From app log, we can see the return value was(-8)VX_ERROR_NO_MEMORY) when TIOVX API vxVerifyGraph was called but no any other available log(vx_print of TIOVX has been disabled)
The internal process of vxVerifyGraph mainly apply necessary shared memory for pipelining.
But no any error slog, just some initiated log like:
"Jan 01 08:00:00.212 shmemallocator.73741 SharedMemoryAllocator: BaseAddress: 0xb8000000 Size: 0x2a000000 (704643072)"

[question]
../vision_apps/utils/mem/src/app_mem_qnx.c
void *appMemAlloc(uint32_t block, uint32_t size, uint32_t align)
int32_t appMemFree(uint32_t block, void *virtPtr, uint32_t size )


We've now found there seems to be a possible reason from app_mem_qnx.c
appMemAlloc and appMemFree, both of reference a global variable of bufs[i], but there is no safe protection for bufs, that means appMemAlloc is not thread safe when multi-thread running for memory.
At least it may cause a memory leak issue, but we cannot sure whether it can result in a null (virtual) address to apps when call appMemAlloc.

We have created more timer threads to test it. In each thread, there is a loop: call appMemAlloc for 10K memory, sleep 10ms then call appMemFree. A null address returned from appMemAlloc occasionally.
So it seems to be a real reason.

Please check whether there is an issue in appMemAlloc.

Thank you.

  • Hi,

    In a quick compare between the version of app_mem_qnx.c from SDK RTOS 8.2 verses SDK RTOS 9.2, the attached delta can be seen.   

    Please take a look and see if these code updates would be assist in the issue being seen.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/app_5F00_mem_5F00_qnx_5F00_82_5F00_to_5F00_92_5F00_delta.patch

    Regards,

    kb

  • Thank you for reply timely. It does make sense. But we must check it carefully for market issues. 

    The difference points from 9.2 is:
    1. append mutex lock
    2. memory mapping method
    3. some optimization for memory management
    4. memory alloc info print

    for point 1, we have also done it and the issue seemed never happen.
    But we cannot sure point 2, 3.  Are there any other issues related with them?
    Theoretically, Is it the best way to transplant all the changes from 9.2 to 8.2?

    Thank you.

  • Hi,

    Glad to hear (1) was addressing the immediate need.   As the TI SDKs continue to mature, each release will have a list of issues fixed and features added.  It always good to keep an eye on this content, and keep an eye on the H/W errata document.

    In general yes, the content that is desired would be required to be ported back to the SDK 8.2. 

    Will work to get the patch which was implemented to specifically address (1), as opposed to the delta between SDK 9.2 and SDK 8.2 which was previously provided.   Will respond no later thanThurs. June 19th.

    Regards,

    kb

  • > Will respond no later thanThurs. June 19th

    Thanks for supporting.

  • Hi, how about the work, have any conclusion?

  • Hi Frank,

    Apologies for delay, I have not had time to generate the patch, and other TI resources were out office.  Will follow up and get back to you.

    Regards,

    kb

  • Unlocking this thread. 

  • Hi Frank,

    Are you still seeing this issue?

    Regards,

    Brijesh

  • Yes,There are still two questions below we've mentioned before:

    > But we cannot sure point 2, 3.  Are there any other issues related with them?
    > Theoretically, Is it the best way to transplant all the changes from 9.2 to 8.2

    (We should ensure is it necessary for 8.2 version to transplant)