• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 32 subscribers
  • Views 784 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.

TM4C1294NCPDT: periodic call to vsnprintf with %f cause stack overflow

Abhijit Acharekar
Intellectual 640 points
Part Number: TM4C1294NCPDT


Dear SupporTeam,

inline
std::string FormatLogString(const CHAR* format, ...) 
{
const INT32 ZERO = 0;
std::string strLog = "FORMATTING ERROR !\n";
va_list args;
va_start(args, format);
CHAR formattedMsg[GCProtocol::MAX_LOG_MSG_STRING_SIZE];

INT32 result = vsnprintf(formattedMsg,
GCProtocol::MAX_LOG_MSG_STRING_SIZE,
format,
args);
if(ZERO < result)
{
strLog = formattedMsg;
}
va_end(args); /*TICS !OAL#015 allow null for logging*/

return strLog;
}

We use above function for var arg formatting 

we have a situation where A2D values fluctuates at a boundary and causes inRange and outRange using %f value(position in cm e.g. 10.2 ) getting logged using above function. We read the A2D count value periodically from two tasks; because of the fluctuation we see inRange and outRange getting logs periodically. We observed stack overflow in this situation and if we get rid of logging %f value, it works fine. we have so many other instances where we log using %f but we don't see any issue.

BTW, we don't log directly from our TIVA C base board; our logger utility will send string to our master board which supports logging.

ccs - 901

compiler version - TI v18.12.1.LTS

tirtos_tivac_2_16_00_08

Any clue?

Thank you.

Abhijit

  • 0
    TI__Guru*** 135355 points

    Hello Abhijit,

    I understand that this code is executing on our TM4C1294NCPDT device however we are device experts who specialize in the use of device peripherals and features. This question is outside of the scope of the support we provide since it is a general C code question and application specific.

    I would recommend perhaps stack overflow? (Though sometimes a community member may chime in as well...)

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Intellectual 640 points

    Hello Ralph,

    Thank you for your response. I can understand this could be linked with our own application but I am not able digest below questions

    1) Stack doesn't overflow on first call; we see few logs getting generated with correct value for float variable that we log

    2) Why only %f causes stack to overflow; if we remove %f from our log; we don't see the issue.

    3) We monitor the stackpeak for that particular task; all of a sudden it jumps from ~1300 bytes to ~2000 bytes (2048 is our stack size) 

    Thanks & Regards

    Abhijit

  • 0 in reply to Abhijit Acharekar
    TI__Guru*** 135355 points

    Hello Abhijit,

    I have even less understanding than you do if this. I do not use logging like you are doing or have used %f for such purposes as a TM4C device expert. I'm sorry that I cannot help.

    One thing to try maybe is to increase stack size and see if the stackpeak does not increase - then it might just be the cost for that logging. If it goes up to the new stack size, then it is highly likely you have a memory leak.

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Intellectual 640 points

    Hello Ralph,

    Thank you for taking time to respond.

    We have one more observation if we use %.3f it works fine; we don't see stack overflow.

    Can you please explain what could be the memory leak issues w.r.t. stack usage?

    Thank you.

    Regards

    Abhijit

  • 0 in reply to Abhijit Acharekar
    TI__Guru*** 135355 points

    Hi Abhijit,

    I probably used the wrong term - memory leak seems to be specific to malloc commands. Was just meaning that the stack overflow could be due to a buffer size issue or such - if the buffer pointer or buffer overruns, then it can overflow onto the stack. That was what I had in mind.

    Best Regards,

    Ralph Jacobi

  • 0
    Guru 100945 points

    > CHAR formattedMsg[GCProtocol::MAX_LOG_MSG_STRING_SIZE];

    > strLog = formattedMsg;

    > return strLog;

    This code appears to return a dangling reference (pointer to local variable). Depending on what you do with the result, this could cause various kinds of trouble.

    [Edit: Never mind. I missed this part:

    > std::string FormatLogString(const CHAR* format, ...) 

    ]

  • 0 in reply to Ralph Jacobi
    Intellectual 640 points

    OK Got it.

    Yes, we see if we use %f in variable argument string, it suddenly increases stack requirement. Why is it so? Even %.2f or %.3f doesn't reduces the stack requirement.