Hunting for a memory leak.

hi, I'm trying to diagnose a problem that may (or may not) be down to a char array overflowing.

My project consists of a couple of dozen libraries I've written myself, all of which have passed functional testing (each library tested on its own). All libraries have passed all their tests, but the project itself is currently failing (full details listed in numerous other postings - but that's not the current question).

If it is an overflow issue, it's occurred to me that one of the factors is that when I test a library in isolation any overflow will probably effect unused memory, so won't get noticed. It's only when there are more objects in memory that an overflow is likely to corrupt something important. So, is there a technique where I can test just one library on it's own, and deliberately populate all the rest of the dynamic memory with some known value (set everything to NULL or FF). I can then run my tests on that one library, check that all the other memory values are unchanged, thereby confirming if anything in the library is causing corruption.

I think what I'm describing sounds like a nice idea, but i'm not sure there's a practical way of doing this.

Comment / suggestions please?

I don't know if that is possible, but I'm not sure that would help.
Perhaps it is better to check all source code again for buffer overflow.
If you use sprintf, you have to carefully calculate the maximum used buffer size.

When you combine a number of libraries, you might run out of memory soon, that would also result into overwritten memory.
Do you know how much ram is used ?

It's not a foolproof method because it will only detect whether a given piece of memory has ever been used, not whether it has been used for heap and stack at the same time.

The safest approach I can think of would be to avoid writing or using any code that allocates memory from the heap, write a guard word to the memory just above the heap, and check periodically whether the guard word has been overwritten. That won't detect corruption within memory used by the sketch (such as writing outside the bounds of an array) but would enable you to confirm that the stack and heap haven't collided. Not that you could rely on the sketch running well enough to tell you that they have collided if they have, but getting positive confirmation that they haven't would be valuable.