Stack/Heap Overrun?

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Guys,

 

I have been working with my mega644PA for a while now with a fair sized application that still has a few bugs that are very hard to find. In my main loop every minute I run some tests and have response messages outputted back to myself. Every so often (like one out of 10 units I am working for 1 minute randomly once a week) output these debug messages in a constant stream, much faster than could generally processed even without the timer. As such i thing their is either a loose pointer reading program memory, a stack overflow or somehow I am accidentally doing something with the program counter (unlikely) that i don't know of. I am only programming in C and have no direct functions I have written that use the PC directly.

 

Is it perhaps an overflow? Despite my compiler telling me I have only used 50% of program memory and 65% of data memory?

 

Side note, I have a bootloader on the AVR also contributing 10% to the program memory.

 

Any thoughts or criticism would be greatly appreciated!

Last Edited: Fri. Sep 12, 2014 - 11:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sounds like a variable rolling over or maybe an atomicity problem. If you think it is stack being overrun, put 'canary' or 'sentinel' values in the stack area and check for these values being changed at a regular interval. Flash a led or something so it is obvious that the stack has been overrun.

Last Edited: Mon. Sep 8, 2014 - 12:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That was my next move too!

 

Was wondering if JTAG could pick this up though? More to the point, what way I could detect this in a simulated application?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With a debugger you can see how much stack is being used and you can manually put values in the memory to see if they get overwritten. Similarly with a simulator. It can be a bit of a hard slog - you tend to find what is not the problem and then slowly rule out things until you narrow in on the culprit.

 

note that the compiler only reports static memory usage - if you have large or a lot of local variables this affects stack usage of which the compiler doesn't know about. Code size is black or white - it either fits or it doesn't

Last Edited: Tue. Sep 9, 2014 - 12:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can create a variable called lastvar or something and init it to 0x55 or 0xaa at the start of the program, and check it in the main loop. If it gets overwritten, it will become abundantly obvious in microseconds. The excellent imagecraft compiler has a _Stackcheck() functions that calls a stub called _StackOverflowed() with a paramater 0 or 1 for hw stack or sw stack overflow. I wrote my own _Stackoverflowed() function to replace the stub that did nothing with INTR_OFF(); then print out H or S and hang in a loop.

Imagecraft compiler user

Last Edited: Thu. Sep 11, 2014 - 01:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

personally I fill my stack with 0xaa (0xDEADBEEF is also popular) and periodically check that a band of these values exist between my globals/statics and the stack.

 

if using a rtos I (as a config option) also check that the stack pointer is within bounds on context switches and that the bottom of stack is still marked with a band of at least one 0xaa.

 

I never use malloc in a uC.

regards
Greg