Local variable addresses changing

[Chris Stankevitz]

Hi,

I have some weird behavior in a very large (500,000 line) program that I
boiled down to a few lines:

TCSensorMode::ProcessMeasurement()
{
InternalComplicatedFunction(1.0, 2.0);
int a = abs(1);
int b = abs(1);
int c = abs(1);
int d = abs(1);
int e = abs(1);
int f = abs(1);
int g = abs(1);
}

The abs calls were there to "stimulate" the stack frame pointer and try to
get the error to happen. After the call to d=abs(1), all my local variables
address get offset. Including "this". Then after f=abs(1) they go back to
normal. The "original" version of this function did not have these abs
calls, they were more complicated functions related to my application. It
is interesting that the stack pointer (esp) and the "activation frame"
pointer (ebp) do not change while executing (F10 in the debugger) each line
in the above function.

This problem popped up from time to time over the past 6 months. I have
been at a loss to explain it. Just recently I got fed up and started
commenting out massive amounts of code in an attempt to track down the
problem.

I discovered an iterator was going past end and subsequently was
dereferenced and who knows what. However, this happened long before
ProcessMeasurement() was called (not within ProcessMeasurement as I
suspected I would find).

After I fixed the out of bounds iterator, my local variable address problem
went away. Only time will tell if it will return.

My question:

Could the out-of-bounds iterator from a "long time" ago cause this very odd
local variable adress changing problem after d=abs(1)? Could I have finally
fixed my problem?

Thanks for the help,

Chris

PS: My original post regarding this issue: http://tinyurl.com/5urzd

[Derrick Coetzee [MSFT]]

"Chris Stankevitz" <ch******@stankevitz.nospamplease.com> wrote:

TCSensorMode::ProcessMeasurement()
{
InternalComplicatedFunction(1.0, 2.0);
int a = abs(1);
int b = abs(1);
int c = abs(1);
int d = abs(1);
int e = abs(1);
int f = abs(1);
int g = abs(1);
}

After the call to d=abs(1), all my local variables
address get offset. Including "this". Then after f=abs(1) they go back to
normal.

Could the out-of-bounds iterator from a "long time" ago cause this very odd local variable adress changing problem after d=abs(1)?

The short answer is, yes: out-of-bounds writes can cause literally any
phenomenon at all to occur, especially strange ones such as the one you
describe. The odd thing, though, is that your explanation precisely
describes a corrupted stack pointer or base pointer, yet you say these
registers aren't changing. My first suspicion was an uneven sequence of
pushes and pops due to overwritten code. Even more strangely, I'd think if
abs were going to corrupt the stack it would have already done so with the
first call. It's possible your assignments to local variables are
overwriting stack locations that are used for other purposes. Have you tried
stepping through it at the assembly level?

Another approach is to precisely track the effects of your overflow problem.
Depending on what version of what debugger you're using, there may be a
feature to set a hardware breakpoint on a memory location so that it breaks
when the location is read or written. You can use this to determine who else
uses the overwritten location and how they are affected, and how in turn
this might affect your problem code.

I would definitely undo the fix long enough to confirm that the bug is
really corrected, but merely masked. The last thing you need is to replace a
reproducable bug with one that only your customers can reproduce. I hope one
of these techniques works for you.
--
Derrick Coetzee, Microsoft Speech Server developer
This posting is provided "AS IS" with no warranties, and confers no rights.

[Chris Stankevitz]

Derrick,

Thanks for your response.

And thanks to MSFT for giving us access to devs like Derrick.

Chris

"Derrick Coetzee [MSFT]" <dc******@online.microsoft.com> wrote in message
news:uh*************@TK2MSFTNGP15.phx.gbl...

"Chris Stankevitz" <ch******@stankevitz.nospamplease.com> wrote:

TCSensorMode::ProcessMeasurement()
{
InternalComplicatedFunction(1.0, 2.0);
int a = abs(1);
int b = abs(1);
int c = abs(1);
int d = abs(1);
int e = abs(1);
int f = abs(1);
int g = abs(1);
}

After the call to d=abs(1), all my local variables
address get offset. Including "this". Then after f=abs(1) they go back
to
normal.

Could the out-of-bounds iterator from a "long time" ago cause this very

odd

local variable adress changing problem after d=abs(1)?

The short answer is, yes: out-of-bounds writes can cause literally any
phenomenon at all to occur, especially strange ones such as the one you
describe. The odd thing, though, is that your explanation precisely
describes a corrupted stack pointer or base pointer, yet you say these
registers aren't changing. My first suspicion was an uneven sequence of
pushes and pops due to overwritten code. Even more strangely, I'd think if
abs were going to corrupt the stack it would have already done so with the
first call. It's possible your assignments to local variables are
overwriting stack locations that are used for other purposes. Have you
tried
stepping through it at the assembly level?

Another approach is to precisely track the effects of your overflow
problem.
Depending on what version of what debugger you're using, there may be a
feature to set a hardware breakpoint on a memory location so that it
breaks
when the location is read or written. You can use this to determine who
else
uses the overwritten location and how they are affected, and how in turn
this might affect your problem code.

I would definitely undo the fix long enough to confirm that the bug is
really corrected, but merely masked. The last thing you need is to replace
a
reproducable bug with one that only your customers can reproduce. I hope
one
of these techniques works for you.
--
Derrick Coetzee, Microsoft Speech Server developer
This posting is provided "AS IS" with no warranties, and confers no
rights.