I am working on a C++ project for a SAM3S chip.
C and especially C++ are notorious for having memory leak issues.

On Windows or Unix, there are several great tools for finding and debugging memory issues,
but what about in an embedded system.

Does anyone know of any tools that would work for a SAM3S project?
I'm using Atmel Studio 6, which uses gcc for the compiler.

Thanks,
Paul

Embedded has hideous problems with fragmentation with dynamic allocation.

Problem is the M3 has very little memory, and no MMU/protection mechanisms.

You could instrument malloc/free and check how many allocation occur vs frees. You could tag the allocations, and catch multiple release attempts. Other methods like poisoning the released memory would require you not to really free() the space, but you'd likely run out of RAM to work with. Not a problem with a PC with 4GB, with virtual/paging support.

Build a test harness and test the core C/C++ code on a PC first. If you have good abstraction you could emulate/simulate the operating environment.

Very good points and suggestions. Thank you.

I've been playing in my mind, with some kind of base class, that would be the sole source for getting references to objects and would keep a reference count. When the count is 0, it would delete itself.

I realize this is not detection, but more mitigation.

I'm mostly concerned about not deleting allocated objects and also attempting to use deleted objects; and less concerned about things like over writing arrays.

I guess you are not familiar with any existing code/tools out there for the ARM environment. I can't be the first person to be concerned about this issue.

Thanks again.
Paul

Well I'm sure some things do exist, and static analysis tools. The ARM9 with an MMU can do page faulting tests like an x86.

As for the M3 there are probably tools using a trace-pod, or large external memories which could catch access post release.

Realistically though some of the software solutions of wrapping malloc/free, and new/delete, are cheap and effective to implement, so I don't see it would be a big business opportunity. The more industrial embedded compilers probably have debug libraries addressing the issue.

If your code is sufficiently portable you could run it in a over specified system, enable a lot of debugging and beat it there.

The far bigger problem will be one of fragmentation and garbage collection. Dynamic allocation is generally avoided like the plague by most embedded devs I know because of the fragmentation and leaking being so fatal.

good comments. Thanks.