Re: Local variable addresses changing

• Previous message: Ronald Laeremans [MSFT]: "Re: Visual C++ Toolkit 2005??"
• In reply to: Chris Stankevitz: "Local variable addresses changing"
• Next in thread: Chris Stankevitz: "Re: Local variable addresses changing"
• Reply: Chris Stankevitz: "Re: Local variable addresses changing"
• Messages sorted by: [ date ] [ thread ]

Date: Fri, 18 Feb 2005 12:55:26 -0800

"Chris Stankevitz" <chris-01@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.

• Previous message: Ronald Laeremans [MSFT]: "Re: Visual C++ Toolkit 2005??"
• In reply to: Chris Stankevitz: "Local variable addresses changing"
• Next in thread: Chris Stankevitz: "Re: Local variable addresses changing"
• Reply: Chris Stankevitz: "Re: Local variable addresses changing"
• Messages sorted by: [ date ] [ thread ]