But it is the result of a memory leak. This, as you rightly say, failing to manage your memory effectively. In other systems, such a computers as opposed to processors they run an occasional garbage collection routine that reorganises the cache. These do not have an equivalent on any embedded processor i have come across.
I think we are just arguing over semantics here, just the sort of thing that blows a thread off piste.
No, your interpretation is wrong.
At the moment when M = null, ditfactor is not undefined, it simply remains equal to the value set for the previous character in the array. Also, the fact that a value is undefined does not mean that it is infinite. An undefined value is a random number from the range of int values - that is, from -32768 to 32767. That is, in the worst case, the delay due to this will be 32767 * 100 millisecs - that is, about 8 hours, and not years at all.
It your case, the warning is related to the first iteration of the Morse loop. To hide the message you have to initialize the ditfactor with any reasonable value, for example zero.
Are you sure there are memory leaks? Try monitoring free memory for a day to check it.
Sure it’s semantics - but there is a real difference. A leak is a bug the developer left and can be fixed, fragmentation is a whole different concept which relates more to the memory size and lack of garbage collection.
The reason I was reacting is that I think it’s unfair to say the String class is buggy and will leak memory. It does not. Most issues I have seen also with the String class do not really relate to fragmentation but more to just having not enough memory for the data duplication and thus operations failing to be executed.
I don’t like the String class on the small AVR platform and would indeed recommend to use cStrings instead but I also want to be fair and not misrepresent that piece of code.
Are you certain that this Is what the OP means? I'm not, and was addressing the OP's problem, not picking a fight about the definition of "memory leak".
I was reacting to your statement - not "picking a fight" because I find this misleading.
case closed as far as I'm concerned, I've said my piece.
Can't bring yourself to answer the question?
There isn't a single string in OPs code.
As others suggested, he needs a heartbeat LED or some debug messages before concluding its even a memory leak.
loop code seems like it might just toggle back and forth between if(nighttime) and else blocks cancelling the increase and decrease of filter, or it can be that its not night time and
PhotoTransistor level is below 987, which seems like it will go through the loop and do nothing, or another problem that he cannot diagnose
True.
If you had paid the slightest bit of attention to this thread, you would have noticed that the OP had not posted any code at the time, but merely asked a general and rather confused question.
Are there any functions with known memory leaks or other issues
(emphasis added for others not paying attention)
Thank you for your contribution!
I was not trying to guess what the OP wrote, I was answering to you and my disagreement with your assertion.
So I was not trying to ignore your question, just trying to explain it was not relevant in my context (I accept you could see that differently).
To me the answer to OP's initial question was given in post #2
I'll stop the digression here, no need to debate this and derail the thread.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.