I have an intermittent problem with memory leakage. On the average, it happens every 3h. When I reset the processor, it works again for some time, repeating the cycle. It is not hardware: the same problem occurs on 2 different Atmega1280 boards.
It is clear that I have a memory problem: part of the code checks the consistency of a 78-byte data structure and it tries to write and check this structure (a 200-iterations loop). I can see (via LCD) the "trash" on this data structure just after writing the correct data using different functions. This is the scenario that the program is "locked" and if continues after the loop, the behavior of the device is unpredictable. Therefore, the leakage seems to be caused by the mentioned functions and their usage of the RAM memory.
Note: I am not using recursivity when calling the functions.
My questions to this forum are specific to local variables:
Is it necessary to "free" local variables used in the functions?
If the above answer is positive, how to "free" the memory used by these variables?
Negative. Unless you use malloc to get memory and don't release, your local variable is just a range of RAM on the stack and there does not even need to manually release, the stack pointer returns to the old value upon return of a function so local variables are destroyed after the function returns.
ionito:
I can see (via LCD) the "trash" on this data structure just after writing the correct data using different functions. This is the scenario that the program is "locked" and if continues after the loop, the behavior of the device is unpredictable. Therefore, the leakage seems to be caused by the mentioned functions and their usage of the RAM memory.
I'd better dollars to donuts you don't have a memory "leak" (which is memory allocated but never freed when no longer needed, yet continuing to allocate new memory causing usage of RAM to grow), but instead, you have a memory over- or under-flow. This happens, most notably, when using arrays and forgetting to check the bounds of the array when using incrementing indeces, and so forth. This is more than likely why you're seeing "garbage data" in your printed data - if it's at the beginning of your data, you likely overflowed the variable before it.*
But, without seeing code - that would be nearly impossible to ascertain at a distance.
If you're not using new or malloc, then you're likely not having anything like a memory leak. (As already stated.)
it's actually more complex than this, but I'm not sure I'm qualified to explain heap, stack, and how variables are declared - I've just had to fix a lot of similar issues myself =)
Strings (and I mean Arduino WString.h class String) use malloc() a good deal and I would not be surprised that your heap can get fragmented to the point that you have memory problems. Do you use class String in your parser?
Another speculation: 3 hours ~= 1.0e+7 ms. Do you have a timing calculation that uses 7 figure decimal numbers (or maybe floats)?
A proper analysis would require looking at your sketch and knowing what it is meant to do.
Wow guys: you really helped me a lot!!! Based on the comments, I tried some options and finally discovered what was the problem.
It is not the local variables.
No memory leak.
While I had the problem, I was not using String class due to previous huge problems I had (I said in a post that this class was a "piece of trash" due to the problems it created).
While I had the problem, I had already converted all usage of String to array of chars.
I double checked the size of the array of chars. Due to previous issues, I had already declared each array with one more char than necessary.
How I solved the problem: using global variables in some functions!!!
I detest to do this because it increases the chances of bugs... but I had to.
Solution: I converted all functions that return array of chars into void functions. These functions just manipulate specific global variables which are "array of chars".
Result: All the problems solved. Almost 6h passed and no "trash"/memory corruption.
Explanation: So far, I cannot give a good one. I am using IDE 0021. The old code is perfectly functional except by the mentioned issues. The new code do the same; probably, it spends more RAM but it is working nicely.
Solution: I converted all functions that return array of chars into void functions.
Almost certainly what you were doing was returning a pointer to a local variable that went out of scope. While that memory will not be immediately overwritten, pointing to data on the heap is dangerous because you never know when the memory will be clobbered.
Solution: I converted all functions that return array of chars into void functions.
Almost certainly what you were doing was returning a pointer to a local variable that went out of scope. While that memory will not be immediately overwritten, pointing to data on the heap is dangerous because you never know when the memory will be clobbered.
Does the compiler not at least throw a warning when you do that? I haven't tried such in arduino, but I know Qt will not compile when you attempt to return a pointer to a local variable from within a method or function.
Solution: I converted all functions that return array of chars into void functions.
Almost certainly what you were doing was returning a pointer to a local variable that went out of scope. While that memory will not be immediately overwritten, pointing to data on the heap is dangerous because you never know when the memory will be clobbered.
That was an excellent guess. Why have I not guessed it? I bet that was what's happening. If you use locally defined char arrays, another problem that I often watch out for is when you call this function, there may not be enough stack space to assign it local variable, if you have many layers of function calls.
Does the compiler not at least throw a warning when you do that? I haven't tried such in arduino, but I know Qt will not compile when you attempt to return a pointer to a local variable from within a method or function.
No, no warning from the Arduino IDE compiler... even using verbose mode.
No, no warning from the Arduino IDE compiler... even using verbose mode.
Actually, the compiler (probably) does generate a warning, but the Arduino IDE invokes the compiler with the warnings option turned off. Why is a subject of great debate.