Strange memory address in M3VPSS exception trace.

Jason Hsui

I often meet a strange exception when deleting SwMs link and re-create SwMs link in DVR RDK 4.0 with config_1G_256MLinux.bld

I skipped link_vpss.cmd in makerules/rules_m3.mk because I Added some code to M3VPSS code so it's size exceed the size of OCMC1_RAM.

So the code will be linked to DDR3 memory space.

The exception occured in ti_sdo_ipc_heaps_HeapMemMP_getStats called by utilsmem_memstats_getfreestats in macro UTILS_MEM_ENABLE_MEMLOG,

which is placed in SwMsLink_drvCreate.

The exception information is here:

[m3vpss ] Unhandled Exception:
[m3vpss ] Exception occurred in ThreadType_Task
[m3vpss ] handle: 0x3edb52e8.
[m3vpss ] stack base: 0x3eb44e60.
[m3vpss ] stack size: 0x10000.
[m3vpss ] R0 = 0x000007f1 R8 = 0x00000004
[m3vpss ] R1 = 0x73613d22 R9 = 0x3edb31c0
[m3vpss ] R2 = 0x00000000 R10 = 0x9dc56fd4
[m3vpss ] R3 = 0x00000400 R11 = 0xffffffff
[m3vpss ] R4 = 0x3eb54ce8 R12 = 0x00000000
[m3vpss ] R5 = 0xc223d423 SP(R13) = 0x3eb54ca8
[m3vpss ] R6 = 0x3edb31c0 LR(R14) = 0x9da3c4bb
[m3vpss ] R7 = 0x00000000 PC(R15) = 0x9da5aba4
[m3vpss ] PSR = 0x61000000
[m3vpss ] ICSR = 0x0440f803
[m3vpss ] MMFSR = 0x00
[m3vpss ] BFSR = 0x82
[m3vpss ] UFSR = 0x0000
[m3vpss ] HFSR = 0x40000000
[m3vpss ] DFSR = 0x00000000
[m3vpss ] MMAR = 0xc223d427
[m3vpss ] BFAR = 0xc223d427
[m3vpss ] AFSR = 0x00000000
[m3vpss ] Terminating Execution...

I disassembled the firmware and got the assemble code (I add some notes in these code):

9da5ab58:              ti_sdo_ipc_heaps_HeapMemMP_getStats__E:
9da5ab58:               .thumb
9da5ab58:              .text:ti_sdo_ipc_heaps_HeapMemMP_getStats__E:
9da5ab58: F8B5             PUSH            {R3, R4, R5, R6, R7, LR}
9da5ab5a: 0646             MOV             R6, R0                           R6 = obj
9da5ab5c: 706A             LDR             R0, [R6, #0x24]
9da5ab5e: 0C46             MOV             R4, R1                           R4 = stats
9da5ab60: 2060             STR             R0, [R4]                           stats->totalSize = 0;
9da5ab62: 0020             MOVS            R0, #0x0
9da5ab64: 6060             STR             R0, [R4, #0x4]                 stats->totalFreeSize=0;
9da5ab66: A060             STR             R0, [R4, #0x8]                stats->largestFreeSize=0;
9da5ab68: B068             LDR             R0, [R6, #0x8]
9da5ab6a: F1F76FF9         BL              0x9DA4BE4C                 GateMp_enter
9da5ab6e: 0746             MOV             R7, R0                            R7 = key
9da5ab70: B08A             LDRH            R0, [R6, #0x14]             R0 = obj->cacheEnabled
9da5ab72: 38B1             CBZ             R0, 0x9DA5AB84
9da5ab74: 7068             LDR             R0, [R6, #0x4]
9da5ab76: 0123             MOVS            R3, #0x1
9da5ab78: 47F6FF72         MOVW.W          R2, #32767
9da5ab7c: 0821             MOVS            R1, #0x8
9da5ab7e: 0830             ADDS            R0, #0x8
9da5ab80: 0AF07EFB         BL              0x9DA65280                first calling Cache_inv
9da5ab84:              $C$L647:
9da5ab84: 7068             LDR             R0, [R6, #0x4]
9da5ab86: 8068             LDR             R0, [R0, #0x8]
9da5ab88: DEF7D8FA         BL              0x9DA3913C               call SharedRegion_getPtr
9da5ab8c: 0546             MOV             R5, R0                            R5 = curHeader
9da5ab8e: BDB1             CBZ             R5, 0x9DA5ABC0           if (R5 == 0) jump to 0x9DA5ABC0 GateMp_leave
9da5ab90:              $C$L648:
9da5ab90:              $C$DW$L$ti_sdo_ipc_heaps_HeapMemMP_getStats__E$4$B:
9da5ab90: B08A             LDRH            R0, [R6, #0x14]
9da5ab92: 30B1             CBZ             R0, 0x9DA5ABA2           if (0 == obj->cacheEnabled) jump to 0x9DA5ABA2
9da5ab94:              $C$DW$L$ti_sdo_ipc_heaps_HeapMemMP_getStats__E$4$E:
9da5ab94:              $C$DW$L$ti_sdo_ipc_heaps_HeapMemMP_getStats__E$5$B:
9da5ab94: 0123             MOVS            R3, #0x1
9da5ab96: 47F6FF72         MOVW.W          R2, #32767
9da5ab9a: 0821             MOVS            R1, #0x8
9da5ab9c: 2846             MOV             R0, R5
9da5ab9e: 0AF06FFB         BL              0x9DA65280                second call Cache_inv
9da5aba2:              $C$DW$L$ti_sdo_ipc_heaps_HeapMemMP_getStats__E$6$B:
9da5aba2:              $C$DW$L$ti_sdo_ipc_heaps_HeapMemMP_getStats__E$5$E:
9da5aba2:              $C$L649:
9da5aba2: 6168             LDR             R1, [R4, #0x4]                 get &stats->totalFreeSize
9da5aba4: 6868             LDR             R0, [R5, #0x4]                 get &curHeader->size
9da5aba6: 4018             ADDS            R0, R0, R1
9da5aba8: 6060             STR             R0, [R4, #0x4]
9da5abaa: A168             LDR             R1, [R4, #0x8]
9da5abac: 6868             LDR             R0, [R5, #0x4]
9da5abae: 8842             CMP             R0, R1
9da5abb0: 88BF             IT              HI
9da5abb2: A060             STRHI           R0, [R4, #0x8]
9da5abb4: 2868             LDR             R0, [R5]
9da5abb6: DEF7C1FA         BL              0x9DA3913C
9da5abba: 0546             MOV             R5, R0
9da5abbc: 002D             CMP             R5, #0x0
9da5abbe: E7D1             BNE             0x9DA5AB90
9da5abc0:              $C$DW$L$ti_sdo_ipc_heaps_HeapMemMP_getStats__E$6$E:
9da5abc0:              $C$L650:
9da5abc0: B068             LDR             R0, [R6, #0x8]
9da5abc2: 3946             MOV             R1, R7
9da5abc4: F0F7B0F9         BL              0x9DA4AF28                call GateMp_leave
9da5abc8: F8BD             POP             {R3, R4, R5, R6, R7, PC}

My question are:

1. Why the value of R4 and R6 are in 0x3XXXXXXX memory space?

I just know that DDR momory space is in 0x80000000 to 0xBFFFFFFF and OCMC RAM are 0x40300000 and 0x40400000.

2.Why R5 (curHeader) is pointing to 0xc223d423 which is return by SharedRegion_getPtr?

Thanks!

B.R.

over 12 years ago

0 Badri Narayanan over 12 years ago

TI__Guru 59700 points

Address 0x3XXX_XXXX is valid address. On M3 DDR is mapped to 0x3000_0000 address range so 0x3xxx is valid address. The address 0xc223d423 is an invalid address on 1G build and that is the reason for the exception.Exception indicates SwMs output buffer overflow . THis is most likely issue with your application swms layout creation where the swms output buffer is created for some resolution but layout configuration from application is for a larger resolution. You should be able to debug this by checking the swms layout prints which are printed when layout is changed.

0 Jason Hsui over 12 years ago in reply to Badri Narayanan

Intellectual 765 points

Hi Narayanan,

Thank you for your quickly reply.

But it didn't create new layout because the exception occured before creating new layout and swms output buffer.

As the code show:

Int32 SwMsLink_drvCreate(SwMsLink_Obj * pObj, SwMsLink_CreateParams * pPrm)
{
    Semaphore_Params semParams;
    Clock_Params clockParams;
    UInt32 winId;
    Int32 status;
    UInt32 i, j;
    Bool vip0Exist = FALSE;
    Bool sc5Exist = FALSE;
#ifdef TI_816X_BUILD
    Vps_PlatformCpuRev cpuRev;
    UInt32 chId;
#endif

#ifdef SYSTEM_DEBUG_SWMS
    Vps_printf(" %d: SWMS-%d: Create in progress !!!\n", Utils_getCurTimeInMsec(), GET_MP_ID(pObj));
#endif

    memStatsDebug = TRUE;

    UTILS_MEMLOG_USED_START();   /* This is the place that exception occured, no buffer is created here */
    SwMsLink_drvResetAvgStatistics(pObj);
    pObj->inFramePutCount = 0;
    pObj->inFrameGetCount = 0;

    pObj->frameCount = 0;
    pObj->totalTime = 0;

    pObj->skipProcessing = 0;
    pObj->switchLayout = FALSE;
    pObj->rtParamUpdate = FALSE;
    pObj->vipLockRequired = FALSE;
    pObj->enableBufCopy = TRUE;
...

I also check SR2(When exception occured, Memory_getStats was working on SR2 handle),

There was more than 160MB free memory.

Thank you!

B.R.

0 Badri Narayanan over 12 years ago in reply to Jason Hsui

TI__Guru 59700 points

THis has nothing to do with free memory. If you allocate 10 bytes and write 11 bytes it will corrupt the SharedRegion heap and it can cause such exceptions. The exception indicates the memory was corrupted in the previous iteration. Do Memory_getStats after every link create and delete to check which link is corrupting memory

0 Jason Hsui over 12 years ago in reply to Badri Narayanan

Intellectual 765 points

After reading the SharedRegion source code, I finally know how SharedRegion heap organizes buffers.

So I know the cause, VIP captured too much data into pre-alloced buffer when changing videdo source from 720P to 1080P.

I force capture driver with 1080P size will solved this problem.

Thank you very much.

B.R.

0 Badri Narayanan over 12 years ago in reply to Jason Hsui

TI__Guru 59700 points

Excellent analysis. Thanks for sharing the info on root cause.

Processors

Processors forum

Strange memory address in M3VPSS exception trace.