ESP32 Forum

We detected a stack leak in something that was not supposed.

It only occurs in the first call to a function, not in the following calls.

We reduced the problem to a simpler example that everyone can test:

Example 1:
    Calling this function in task in task main
    
  Before running function:
.----------+-------+----------+-------+------
| Process | STATE | PRIORITY | FREE | PID
'----------+-------+----------+-------+------
main X 1 5248 4

  After:
.----------+-------+----------+-------+------
| Process | STATE | PRIORITY | FREE | PID
'----------+-------+----------+-------+------
main X 1 5248 4 ----> OK

    No change in available free memory in task --> OK
/-------------------------------------------------------------------------------------------------------------------

Example 2:
    Calling this 2nd function in task main
    
  Before running function:
.----------+-------+----------+-------+------
| Process | STATE | PRIORITY | FREE | PID
'----------+-------+----------+-------+------
main X 1 5248 4
    
    After:
    
.----------+-------+----------+-------+------
| Process | STATE | PRIORITY | FREE | PID
'----------+-------+----------+-------+------
main X 1 4912 4 ---> NOK

The task "free memory" never recovers to the previous value.
    Calling the function again does not decrease the free memory any further.

Any ideas of what is wrong?

We detected a stack leak

I doubt that.

It only occurs in the first call to a function, not in the following calls.

Which may hint at the actual problem.
What is the number "FREE" supposed to mean? Where does it come from?

Any ideas of what is wrong?

I guess the meaning of "FREE" in this case differs slightly from what one usually expects, so it may just be a less-than-perfect choice for the label. Cf. https://ecos.freertos.org/Documentation ... hWaterMark

Hi "Microcontroller".

The free number of bytes it what the function vTaskList() return in string relating to all tasks.
So task main() passes from 5248 free bytes to 4912 free bytes, loosing 336 bytes.
This is ONLY an example of much larger problem that we detected.

It is normal that the number of free bytes reduces during the execution of a function, because all the variables are allocated in the stack, as supposed. However, after the function ends, the stack should have returned to the original free size. It is C and the basic functioning of the C.
If you use for example an array of 100 bytes, the stack returns to the original size.
With an array of 500, even 200 bytes, it does not return to the original free size, and with an array of 100 bytes it return to the original free size. Strange! Looks a malfunction of the compiler.

The only good thing thing, but not enough, is that we do not continue to loose stack size if we call the function several times, BUT we loose that memory to other functions that also need stack memory. 10 functions like this in a row and we loose all the stack.

We are solving this problem with pointers and mallocs, but it was not supposed to malloc space for temporary variables with 200 or 300 bytes.

Looking at the source confirms my suspicion that the stack size output is in fact the respective "high water mark", which by its definition can only ever move in one direction during program operation. In this case "FREE" == "was never used" != "currently not used".

So no problem and no "stack leak" here. - But the FreeRTOS documentation could definitely be improved w.r.t. the output of vTaskList().

(Btw, the local "test" arrays in your functions are optimized away completely by the compiler at any optimization level above "debug" because they're never used.)

Hi, Microntroller.

OK, that is a good explanation.
Thank you!

Nevertheless, we saw the number decrease -> increase > decrease. So probably is not that simple as a High Watermark.

Nevertheless, we saw the number decrease -> increase > decrease. So probably is not that simple as a High Watermark.

Any chance a task was deleted and later recreated?