Help with Memory overrun / Memory leak

Chip Cox

I have a moderately sized program ( larger than yall probably want me to post here 1300+ lines ) and I'm running into what I believe is a memory leak. I'm looking for a tool that would help find it. It's particularly a pain because, adding debug statements seems to make it go away depending on where they are added ( I know it's just moving it to somewhere I'm not looking ). Unfortunately, there doesn't seem to be any rhyme or reason to where they are added to make it go away. If there were I could narrow down the statement that is over running it's bounds. When it runs over, it hits the first character in a byte memory block in one of my dat blocks. It's not the first memory location in the dat block. I've tried adding filler above and below it and it still blows on the same byte so it appears to be referenced against that particular storage location. Any suggestions on tools to aid in tracking this down. It's written in spin.

Mike Green

There really are not any tools to help with this. You could create your own by replacing all stores into arrays with calls to a method that does the actual store and checks bounds as it does so. You could do this with a simple string processor like AWK. A lot depends on how your program is written. You could replace all statements like this

byte[pointer] := value

with

storeByte(pointer, value, lower, upper, stringAddress)

where lower is the lowest allowed address and upper is the highest allowed address. The storeByte method would check the value of pointer against these two limits and display an error message with all the supplied information if the pointer is outside the supplied limits. You'd have a similar routine for words and longs if you need the functionality. You could have similar routines for specific named arrays if that's needed or you could do

storeByte(@array + index, value, lower, upper, stringAddress)

To save time and space, you'd precompute lower and upper and store them in a variable during your program's initialization since they're fixed throughout the program's execution. The string would identify the area of the program and you'd probably put them all in a DAT section since they might be used several times.

It's often more efficient to just put debug statements in areas where a pointer is incremented or decremented or otherwise computed to catch logic errors rather than just testing for valid pointers all the time.

Heater.

Unless you have implemented your own memory allocator this is no "memory leak".

"Memory leak" has a specific meaning in computer programming. It's refers to obtaining blocks of memory from a memory pool, perhaps by requesting them from your operating system, and the forgetting to return them to the pool. As your program runs it can "leak" more and more memory until nothing is left and the program fails. Or even the ehole operating system fails.

So it's probably a memory corruption of some kind:
a) Perhaps you are accessing an array with an index that is out of bounds.
b) Perhaps you are accessing memory via a pointer which is not set correctly.

As Mike says these can be hard to find.There are no tools to help with this that I know of.

For case a) Mikes idea of using methods to access array elements and perform bounds checking is excellent.
For case b) take a day off from looking at the code. Then come back and check that you are using (or not using) the @ operator correctly in all places.

Chip Cox

Wow, thanks, I hadn't thought about that one. I'll give that a try today!!! At least I will if my wife doesn't add anything else to the honey-do list. <grin>.

Dave Hein

Write a method that prints a message every time the DAT byte value changes, and start the method in another cog. You can then add trace prints in your main code to narrow down when the memory scribbling occurs. The method would look like this:

pub WatchByte(addr) | val, prev
  prev := byte[addr]
  repeat
    val := byte[addr]
    if val <> prev
      ser.str(string("**** Value changed to "))
      ser.hex(val,2)
      ser.tx(13)
      prev := val

EDIT: A lot of weird memory corruption problems are caused by stack overflows. If you are starting other cogs you could try increasing the sizes of the stacks to see if the problem goes away. There are stack checking objects in the OBEX, or you can write one yourself by filling the stack space with a known value, and then check the stacks after running your program to see how many magic words remain at the end.