Go Down

Topic: Locating memory leaks in Arduino Code? (Read 5227 times) previous topic - next topic

Brian Neltner

Dear Arduino Lovers,

I am writing a fairly large program for Arduino Demilova (atmega328), which utilizes a port we did of liblo (an open sound control processing library), as well as a fixed version of the port of uIP produced by async_labs.

When I send the arduino OSC packets over wifi, it works great for a while, but then will eventually grind to a halt, with the state it is outputting held constant. The entire chip is not frozen because the PWM brightness output is still functional (i.e. it does not go to either dark or full on). So, the backend is still running, but reception is frozen.

When I run nearly identical code on the Maple board, it runs continuously without this problem.

So, my question is, how can I run down a problem like this? Is there an ICD or something that I can use to look at the state of the arduino's memory when it is frozen? I can't blame hardware because the same shield is working on my other system.

Brian Neltner


Finding errors like these can be very difficult.

If your code is somewhat modular, you could start be trying to disable different parts of the code, to try to isolate the problem to a specific module or part of the code, and then repeat within that module.

Also try to send variuos messages to the serial monitor from different parts of the code, this way you can, from the last message sent to the serial monitor before the program stops responding, figure out in which part of the program the problem should be found.


You are right, my guess would be that if there was a memory leak, then everything would stop including pwm. But it may keep going in a 'lucky' bit of memory with its interrupts.

The best way to avoid memory leaks is to never allocate anything dynamically. Its a rare situation that justifies it on a little device like the Arduino. Careful design and statically allocated buffers can usually avoid it.
I write books about Arduino and Electronics: http://simonmonk.org


I used Valgrind (http://valgrind.org/) to detect memory leaks when developing gcc based applications. I don't know off my head if it supports avr-gcc, but you can certainly take a look.


Sep 27, 2010, 01:54 pm Last Edit: Sep 27, 2010, 02:13 pm by focalist Reason: 1
Identifying a memory leak is simple- If you spray it with soapy water, you'll see bubbles when the little 1's and 0's come out.  A little putty or some caulk will fix 'er right up.  On a low speed device it's fine, but at gigabit speeds, it could tear your arm clean off.  Nothing's worse than having to mop up after a packet rips open, you'll be cleaning it out of the carpet for weeks... and don't vacuum up the token by mistake (they're tiny and hard to see, get on your hands and knees to make sure), the whole ring will be down till we can order a new one.  (okay, okay, enough recycling of dinosaur crap)

If you overrun the memory, these things go a bit wonky (love the technical term?).. that would be my first guess.  Although as a general practice I don't like doing it, you could declare all your variables globally at the start (fill strings, too) so the memory is allocated there.  Don't use dynamic variables, and the memory image should be the same, at least as far as user code goes.  On the safe side, I'd leave some room for Lib programmers using dynamic allocation of some type.. that would exclude a problem in your code, and you could at least identify if the problem lies elsewhere.. then work backwards.


Sounds like a troubling problem.

Post a reply if you figure out a way other than line by line...

Go Up