CODEWITHSUNDEEP
cembeddedarm7armcc
stephen
stephen

Reputation: 1

Debugging memory issues ARM7

I am having some issues trying to debug what appear to be some very strange behaviors. For example, we have:

static const char* LOG_FORMAT = "0x%02x,%.5f,";

and the pointer changes for no obvious reason. Sometimes to garbage, sometimes to other constant strings (or part of) defined elsewhere in the code. We also occasionally see the code jump to a different section which should not be running (State variable appears to change without being asked to). There are 2 or 3 common failure modes, and they appear to happen at random. It is a relatively large code base and adding or removing some sections changes the failure behavior (or removes it completely) even though those sections are NEVER referenced.

The best theory at the moment is that it is a memory related issue as we have been over all of the recent changes with a fine tooth comb, and the simple act of inserting sections of code to move things around appears to change or remove the behavior.

What are the best ways about debugging this issue or similar issues? Have found the debugger useful at times, and not at others (but that could be user error).

Further notes. ARM7, using Keil µVision 4 and the armcc v4.1 compiler.

Upvotes: 0

Views: 209

Answers (2)

D Krueger
D Krueger

Reputation: 2486

This looks like a stack misalignment issue. Your stack is probably aligned on a single-word (four-byte) boundary instead of a double-word (eight-byte) one.

That's why removing and adding unrelated sections causes different behavior. The stack goes from being aligned to misaligned depending how much data precedes it.

The corrupted format specifier is another clue. A misaligned stack can often cause no issues until a variadic function is called--especially one that is passed a value that needs to be double-word aligned.

To debug this, you should set a breakpoint at the call to printf (or whatever function the format specifier is used for) and take a look at the stack pointer. If SP is not aligned on an eight-byte boundary, you've found the problem.

Upvotes: 0

Lundin
Lundin

Reputation: 215340

This means that you have pointer bugs/memory corruption somewhere in the program... which could be caused by a lot of different things.

The easiest way to spot this is to run the program until start of main, then add "write" breakpoints to the variable. This should directly point out the offending code.

One likely cause is stack overflow, where the stack is placed at a bad memory location, so that upon overflow it starts to overwrite .data or .bss. See this article.

You can debug stack overflows by setting all the stack memory to a known value at start-up (such as 0xAA), let the program run for a while, try to expose it to as many use-cases as possible, then break and check the memory of the stack, to see how deep down the know values are still preserved. If this is close to the end of the stack, then you very likely have a stack overflow.

Upvotes: 1

Related Questions