I have a sketch that stops working (sometimes within hours and sometimes as long as 5 days) that I can't seem to fix; I believe that I have a memory leak, but I'm not 100% positive.
Would a memory leak show up as a slowly building issue in Luci's Memory status graphs? If the memory stays static up until the Yun is unresponsive, would that suggest another issue? BTW, the error that I receive is "nil socket connection" using the arudino.local/data/get command. Resetting the 32U4 using the reset button makes the unit work again, suggesting that it's a memory leak, right?
Otherwise, are there other ways to diagnose a memory leak or other error? Everything compiles fine and runs for a while, but then quits. It's hard to test new changes when it may take up to a week to get the error.
Thanks!
doktorinjh:
Would a memory leak show up as a slowly building issue in Luci's Memory status graphs?
That is showing the memory utilization of the Linux processor. It has no information about the processor that is running your sketch. It is of no use in trying to debug your sketch.
Otherwise, are there other ways to diagnose a memory leak or other error?
This might help?
Thanks ShapeShifter!
I used your advice and installed the example code that you linked to. I had previously added the MemoryFree.h library and ran both of them together. After an hour, or 6 program loops, the values never changed, and then the program stopped responding. According to the memory programs, I had 970 bytes of available SRAM memory after each program loop, there were no changes.
For flash memory, I am using 79% of the program storage space and 52% of the global variables. The program does not use any EEPROM memory.
If this is in fact a memory leak, I would expect to see a steady decline in available SRAM memory leading up to a program shutdown, right? Are there other things to check that might be causing the sketch and 32U4 to lockup after hours/days?
At the time of this reply, the program looped 10 times after a reset and then stopped, there were no changes to the memory values and they were identical to the previous results. This is frustrating...
doktorinjh:
If this is in fact a memory leak, I would expect to see a steady decline in available SRAM memory leading up to a program shutdown, right?
I would agree. If the memory utilization remained constant up until the moment of the crash, I would think that you do NOT have a memory leak issue.
As far as what else might be causing your crashes, it's impossible to say without seeing your code.
Thanks again for taking a look. I've posted the code here: http://pastebin.com/rxdMQ24w
I'm really at a loss as to what it could be!