• Locked Locked
  • Replies 17 replies
  • Subscribers 52 subscribers
  • Views 2074 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Mismatch in value of function parameter

Jitendra Saini
Intellectual 270 points

Hi,

I am facing quite a strange issue where the value of function parameter is not coherent between the caller and called function. let me explain it using a simplified scenario -

int8 *gpui8TmpAddrCaller = NULL;
uint8 *gpui8TmpAddrCallee = NULL;

void fn_callee (uint8 *pui8DescAddr)
{
   gpui8TmpAddrCallee = pui8DescAddr;
   /*fn_validateBuff is a function which validates sanity of header content*/
   ASSERT (STAT_SUCCESS == fn_validateBuffHdr(pui8DescAddr));
}

void fn_caller ( void )
{
   uint8 *pui8UserMem = NULL;
   pui8UserMem = (uint8 *)malloc( 64 );
   if ( NULL != pui8UserMem)
   {
      /* Fill predefined header*/
      fn_fillBuffHdr (&pui8UserMem);
      gpui8TmpAddrCaller = pui8UserMem;
      fn_callee (pui8UserMem);
   }
}

The first function (fn_callee) is invoked periodically from fn_caller with an buffer address passed as argument.

the passed buffer has a fixed header which is validated in the callee function and an assert is raised if validation fails.

I am getting the ASSERT hit after somewhere around ~90 invocations. when I check the value of gpui8TmpAddrCaller and gpui8TmpAddrCallee in expression window, they are completely different but does not look like memory corruption.

I am not able to understand how what might be the cause of this problem and how can I debug it.


I am using the following -
Nyquist C6670 EVM Board
SYS/BIOS 6.34
XDC Tools 3.24
C6000 Code Generation Tools v7.4.1
MCSDK 2.01

Thanks,

Jitendra

  • TI__Guru* 84285 points

    Please show us the contents of memory at the time of the corruption for the memory locations representing the global variables gpui8TmpAddrCaller gpui8TmpAddrCallee. Use the memory browsing window, not the expression window.

  • in reply to Archaeologist
    Intellectual 270 points

    Hi,

    I have attached the zipped archive containing required memory views.

    Please let me know if I could provide some more information.

    Thanks,

    Jitendra

    Memory Dump.zip
  • in reply to Jitendra Saini
    Intellectual 270 points

    One additional point - the memory address passed from caller (gpui8TmpAddrCaller) is a QMSS Monolithic Descriptor base address.

    hope its helpful.

    Thanks,

    Jitendra

  • Guru 26430 points

    This line seems out of place:

    fn_fillBuffHdr (&pui8UserMem);

    are you sure it should not be:

    fn_fillBuffHdr (pui8UserMem);

  • in reply to Norman Wong
    Intellectual 270 points

    Hi Norman,

    Thanks for your reply.

    The mentioned example is a simplified version of the actual code base which as per license, i can't upload here. sorry about that. few points to clarify the situation here -

    1) Even though the function fn_fillBuffHdr takes a uint** as input argument, it only updates the buffer content and doesn't update the base pointer address.

    2) gpui8TmpAddrCaller = pui8UserMem; is done after the above function returns so it should not be a issue.

    3) I also tried changing the prototype as you suggested, no luck :(

    4) This problem does not occur when the function is invoked for first time. I have done single stepping and verified the parameter address and buffer contents. Mismatch occurs only after ~90 invocations.

    I am still having a hard time figuring what might cause such behavior.

  • in reply to Jitendra Saini
    TI__Guru* 84285 points

    I'm sorry, I'm not familiar with the format of that memory dump format, so it's taking me a while to figure out what it says.  What are the addresses of the variables in question?

  • in reply to Jitendra Saini
    Guru 26430 points

    Hard to diagnose without a test case project with the absolute minimum of code. I am guessing this only occurs in the full system. Perhaps your stack is growing into your heap. Try increasing your stack size to see if changes the number of invocations.

  • in reply to Archaeologist
    Intellectual 270 points

    Hi Archaeologist,

    Sorry for taking too long to reply.

    The attached memory dump files were captured from CCS Memory browser tool using the "Save Memory" option. I have attached a snapshot highlighting the same.

    Memory content for both addresses is captured in two formats (8 bit & 32 bit views) which is mentioned in the file names.

    What are the addresses of the variables in question

    The attached memory dump file contains the address of the variable in the Top Row. e.g below is the top few rows of "MemDump_8bit_view_Callee.dat"

    1651 9 893306fe 0 80 a
    00
    00
    00
    00
    40
    80

    This file captures 128 Bytes of memory content in 8-bit format starting from the address of "gpui8TmpAddrCaller" which here is 0x893306fe.

    The rows following the first depict the actual memory content at subsequent memory addresses.

    Thanks,

    Jitendra

  • in reply to Jitendra Saini
    TI__Guru* 84285 points

    Jitendra Saini said:
    This file captures 128 Bytes of memory content in 8-bit format starting from the address of "gpui8TmpAddrCaller" which here is 0x893306fe.

    That's not a legitimate address for a pointer variable on C6000.   Pointer variables must be 32-bit aligned, and that address is only 16-bit aligned.  Please generate the map file and post that.

  • in reply to Archaeologist
    Intellectual 270 points

    for a moment I thought finally the issue is busted but then I validated the memory dump files again and found that I made a typo in my last post :(

    Address in the caller function (gpui8TmpAddrCaller) is 0x8a55b9d0 which is a legitimate address.

    Issue only occurs in callee where the received address (gpui8TmpAddrCallee) is  0x893306fe.

    Sorry for the inconvenience. I am not sure without uploading the actual application code how can I add more clarity to the issue here.

  • in reply to Archaeologist
    TI__Guru* 84285 points

    Please generate the map file and post that.

  • in reply to Jitendra Saini
    TI__Guru* 84285 points

    While I am thinking about this, did you try increasing your stack and heap by a healthy amount?

  • in reply to Archaeologist
    TI__Guru* 84285 points

    First, I note that because you are using BIOS, you are using the BIOS variant of malloc, which behaves very differently than the compiler's default malloc. We may need to get someone familiar with BIOS to explain how it is allocating memory for this program, but we might be able to get by without such help.

    The map file shows that the address of these variables are not as claimed.  The actual addresses are:

    &gpui8TmpAddrCaller == 0x0086006C
&gpui8TmpAddrCallee == 0x008602d4

    This means both variables live in .fardata.6, which makes more sense.

    The addresses you show in the memory dumps are probably the contents of these variables.  0x8a5569d0 falls after gui8GBLHostDescFDQ1, and 0x8a55b9d0 falls after gui8BGLMonolithicDesc16BytePool. I presume the malloc(64) successfully allocated memory from gui8BGLMonolithicDesc16BytePool, and the true address is 0x8a55b9d0.

    You say the problem happens after "~90" invocations; is it always exactly the same number?  If so, the problem is most likely an array bounds overflow; this array is most likely slightly before 0x008602d4.  If it is not always exactly the same number, it is probably a problem with an interrupt routine.  Do you have any hand-coded assembly functions in the program?

  • in reply to Archaeologist
    Intellectual 270 points

    Hi Archaeologist,

    I am off work for next couple of weeks. I shall update the post as soon as I come back.

    Very many thanks for your prolonged help.

    Regards,

    Jitendra

  • in reply to Jitendra Saini
    Intellectual 270 points

    Hi Archaeologist,

    We performed a code cleanup in the concerned path and corrected a few cache coherency issues.

    we could not isolate the root cause of reported problem but system runs fine now.

    Sorry for incomplete discussion thread.

    Thanks a lot for your help

    Jitendra