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.

H264 decoder segmentation fault in DM368 platform

Hi there,

 

The platform am using is DM368 with the DVSDK 2.1's dvtb application to test the performance of H264 codec.

 

Am trying to use the H264 decoder for the first time in this setup. And, it is resulting in segmentation fault while decoding the first video frame. Am passing a h264 media file stored in the nfs as input for the decoder. This media file is the recording of the encoded stream from the same platform and hardware, earlier.

 

Here are the final logs before the segmentation fault:

------------------trace log begin-------------------

[DVTB-LOG]: linux/dvtbVidPlay2.c: Video Decoder <h264dec2> initialized

[DVTB-DEBUG]: linux/dvtbVidPlay2.c: Input File Size = 4874240.

[DVTB-DEBUG]: linux/dvtbVidPlay2.c: Read request = 2097152; Read 2097152 no of bytes. ErrorValue = 0

@15,082,648us: [+0 T:0x40c20490] ti.sdo.ce.video2.VIDDEC2 - VIDDEC2_control> Enter (handle=0x299f30, id=1, dynParams=0x16cd74 (size=0x1c), status=0x16d53c (size=0xb8)

@15,082,801us: [+5 T:0x40c20490] CV - VISA_enter(visa=0x299f30): algHandle = 0x299f68

@15,082,907us: [+0 T:0x40c20490] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(alg=0x299f68)

@15,083,003us: [+0 T:0x40c20490] ti.sdo.ce.osal.SemMP - Entered SemMP_pend> sem[0x2937e0] timeout[0xffffffff]

@15,083,120us: [+0 T:0x40c20490] ti.sdo.ce.osal.SemMP - Leaving SemMP_pend> sem[0x2937e0] status[0]

@15,083,234us: [+0 T:0x40c20490] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Exit

@15,083,345us: [+5 T:0x40c20490] CV - VISA_exit(visa=0x299f30): algHandle = 0x299f68

@15,083,440us: [+0 T:0x40c20490] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter(alg=0x299f68)

@15,083,544us: [+0 T:0x40c20490] ti.sdo.ce.osal.SemMP - Entered SemMP_post> sem[0x2937e0]

@15,083,659us: [+0 T:0x40c20490] ti.sdo.ce.osal.SemMP - Leaving SemMP_post> sem[0x2937e0]

@15,083,759us: [+0 T:0x40c20490] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Exit

@15,083,846us: [+0 T:0x40c20490] ti.sdo.ce.video2.VIDDEC2 - VIDDEC2_control> Exit (handle=0x299f30, retVal=0x0)

[DVTB-DEBUG]: ../core/linux/dvtbVidDec2.c: Video Decode Control => Command : 1

@15,084,080us: [+0 T:0x40c20490] ti.sdo.ce.video2.VIDDEC2 - VIDDEC2_process> Enter (handle=0x299f30, inBufs=0x16d62c, outBufs=0x16d6f0, inArgs=0x16cd90, outArgs=0x16cd9c)

@15,084,215us: [+5 T:0x40c20490] CV - VISA_enter(visa=0x299f30): algHandle = 0x299f68

@15,084,314us: [+0 T:0x40c20490] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(alg=0x299f68)

@15,084,409us: [+0 T:0x40c20490] ti.sdo.ce.osal.SemMP - Entered SemMP_pend> sem[0x2937e0] timeout[0xffffffff]

@15,084,520us: [+0 T:0x40c20490] ti.sdo.ce.osal.SemMP - Leaving SemMP_pend> sem[0x2937e0] status[0]

@15,084,629us: [+0 T:0x40c20490] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Exit

Segmentation fault

------------------trace log end-------------------

 

The back-trace of the stack is as below:

(gdb) backtrace

------------------backtrace log begin-------------------

#0  0x00000000 in ?? ()

#1  0x000a765c in H264VDEC_TI_initialize_Bitstream ()

#2  0x000a2f0c in H264VDEC_TI_decode_header ()

#3  0x000a5fd4 in H264VDEC_TI_decode_1 ()

#4  0x000a5030 in H264VDEC_TI_decode ()

#5  0x0004d45c in VIDDEC2_process ()

#6  0x00031558 in dvtb_vidDec2Decode (vd=0x187450, decDuration=0x40c1fdf0) at ../core/linux/dvtbVidDec2.c:202

#7  0x00044df4 in dvtb_vidDec2DecProcess (vd=0x187450, decDuration=0x40c1fdf0) at ../core/linux/dvtbVidPlay2Core.c:239

#8  0x0003eef8 in dvtb_VidDec2Play (T=0x185688) at linux/dvtbVidPlay2.c:333

#9  0x4002a8f8 in ?? ()

Cannot access memory at address 0x1

#10 0x4002a8f8 in ?? ()

Cannot access memory at address 0x1

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

(gdb)

------------------backtrace log end-------------------

Have attached the complete decoder initialization log file along with the config file.

Any suggestions to debug or fix the issue is appreciated.

Thanks,

Shreya

1374.dvtb_h264file_sf.log

8637.dvtb_dm365.cfg

  • Hi Shreya,

    Your log shows its crashing inside codec. Can you share all your codec params? we are mainly interested in dynamicParams.getDataFxn, dynamicParams.dataSyncHandle and IH264VDEC_Params.inputDataMode and IH264VDEC_Params.sliceFormat parameters.

    Best way to start is Run standalone test application provided with decoder release package.

  • Hello Veeranna,

     

    The dvtb test bench is using core/linux/dvtbVidDec2.c which is based on VIDDEC2_Params instead of the specific IH264VDEC_Param. So, I suspect none of those parameters that you have mentioned are being set explicitly.

     I could not find the implementation of extended param mode in dvtbVidDec2 code. Also, the functions in file dm365/linux/dvtbH264Dec2.c appear specific to h264 decoder (using the  parameters specific to h264 decoder) compared to the generic definitions being used (core/linux/dvtbVidDec2.c).

     The logs suggest the correct interpretation of the codec type:

     ----------trace log begin-----------

    setp viddec2 codec                 h264dec2

     [DVTB-DEBUG]: ../core/linux/dvtbMain.c: Read line : setp viddec2 codec                 h264dec2, 43

    PASS: setp

      ----------trace log end-----------

    I have attached the dvs parameter file for dvtb h264 decoder.

     

    Regarding the standalone test h264 decoder app, it is crashing with segmentation fault as well.

    >Shreya

  • Hi

    Lets use standalone testapp to make debug simple. Can you please check input buf ptr what you are passing to process call. By seeing the log it looks accessing the input buffer(bitstream buffer) makes decoder crash.

    And this test app and dvsdk application used by many costumers, so i feel its something to do with environment.

  • Hi,

    Have attached the gdb back-trace of segfault  (with registers and arguments) from the core-dump collected for both standalone and dvtb test crashes (tar.gz file).

    3660.gdb_dump.tar.gz

    Shreya

  • Hi,

    gdb log standalone test app is not giving much info. Please check inputBufDesc, outputBufDesc, inArgs and outArgs are carrying valid addresses. We have NULL pointer check, but if you are passing invalid pointers than codec cant validate them.

    BTW what is version of decoder you are using?