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.

A_invalidFree error got from H264HPencoder

Other Parts Discussed in Thread: SYSBIOS

Hi Expert,


     We have built up a multi-channel video encoder based on TI's h264HPencoder library on

C6678. It can issue one channel of video encoder to any group of corepacs to C6678. For

example, we can group core 0,2,3 to channel 0, and channel 1,4 to channel 1, etc... And also,

we can delete the channel whenever we need. Different channel can run parrally but no more

than one channel will be run on the same corepac.

     But some of my corepacs will crush after hundreds of times of create and delete. I find

one core has reached the abort function after calling RMAN_freeResources. And I got error

message below:

[C66xx_3] ti.sysbios.heaps.HeapMem: line 345: assertion failure: A_invalidFree: Invalid free
xdc.runtime.Error.raise: terminating execution

But all calling to RMAN_freeResources before the error can return successfully.


So do you know possible reason causing this error?

Thank you~~


Sunzhao

  • Hi Sunzhao,

    Is this error consistent? can you please share more details like

    1) after how many calls of create & delete it will happen.

    2) Specific to configuration like 3 cores in a team, or 4 cores in a team

    3) If possible memory map of the executable to identify any gaps in placement of data etc

    Best Regards

    Rama

  • Also, what version of Framework Components are you working with ?

  • Hi Rama,

    1. You can refer to the attached channel info log for specific core team mapping. 1541.channelinfo.rar The line without leading

       "-------" means creat channel, and the line with leading "---------" means delete channel. In each line,

       there are 2 []. The three numbers in the first[] means channelID, reserve number and core number in

       the current channel.   And the eight number in the second [] means the core team of current channel.

       For example, 

       the first line

       [00 00 04][0 1 2 3 0 0 0 0] means: creat channel 0, it is consists of 4 cores, the DNUM of these cores

       are 0, 1, 2, 3.

       the second line

       ---------------------------------------------[00 00 04][0 1 2 3 0 0 0 0], means: delete channel 0,

       it is consists of 4 cores, the DNUM of these cores are 0, 1, 2, 3.

       After hundreds times of create and delete, in line 1858, I create channel 0 consists of corepacs 0,2,3,6.

       And in line 1861. I delete this channel. But core6 crushed. So the delete is failed, And the encoder keep

       on deleting after that . And I got the error message below:

       [C66xx_6] ti.sysbios.heaps.HeapMem: line 345: assertion failure: A_invalidFree: Invalid free

       xdc.runtime.Error.raise: terminating execution

       ti.sysbios.heaps.HeapMem: line 345,

       I trace HeapMem.c. And find that the value of "addr" in function HeapMem_free is 0. And this function is called

       by  function RMAN_freeResources.

    2. The memory map file is attached here4101.test.rar. My cfg file is here5584.h264hp.rar. All 8 corepacs shared one same .out file.

    Hi Gunjan

    3.  The version of  Framework Components is 3.23.02.16

                                  Sys bios  6.35.1.29

                                  edmalld   02.11.03.03

                                  xdc           3.25.00.48

                                   ipc             1.24.3.23

           It seems that one pointer allocated by HeapMem_alloc has been overwriten(or clear to 0). I am very confused

    by the reason because no more than one codec instance running on the single corepac...

     Thank you for your help!

    Sunzhao

                                

  • Hi Sunzhao

    As codec deletion failure/crash happens before the RMAN_freeResources failure message,
    we should focus on codec deletion failure cause/crash.


    When did the crash happen? Before codec deletion or after that?

    We need to analyze crash log also.

    In single channel, is the issue reproducible?
    If yes, is it consistent always?

    Regards

    Sudheesh