Memory Corruption, Compiler Bug, Or Not?

While tracking down some memory corruption issues, I noticed in one function that a parameter on the stack was always getting set to the value 2, even though it was a pointer. I could see it turn red in the memory view window as its value changed. I thought I had identified a compiler bug. But no, it was not a compiler bug. It was actually a mismatch between the optimizing compiler and the debugger. The x86 optimizer knew that the memory for the stack variable was referenced only one time and then was enregistered, so its stack memory could be used for another local variable. The debugger’s local variable display did not realize this and continued to display the memory value for the local variable – confusing.

On ARM, a similar situation can arise since the first 4 registers (R0, R1, R2 and R3) are used as function parameters. The debugger doesn’t track when a function parameter gets moved to a “permanent” register (R6 for instance) and continues to display the function parameter register’s value as the local variable’s value.