My local variable addresses are changing

  • Thread starter Thread starter Rudy Ray Moore
  • Start date Start date
R

Rudy Ray Moore

I work on a large native c++ application. We have about 15 developers. We
recently moved to "Visual C++ .net 2003 7.1." Two devleopers have seen an
odd problem since we migrated.

The address of local variables change when they are passed to another
function by reference (or when their addresses are passed). The address of
the variable increases by 420 bytes.

An example below illustrates the problem (but the problem does not happen in
this example). While the problem is quite reproducable when it appears, I
cannot make it appear at will.

Looking at assembly doesn't help because in assembly local variables are
listed by their c++ variable name in square brackets (assembly doesn't show
the actual adresses of local variables). The assembly thing is also pretty
hard to use (scroll bar don't work...?).

The problem just appears in a certain "group" of developers (math people,
not programmers), so I might suspect they are doing something weird in their
project files or coding.

Does anyone have any clues about how I can solve this problem?

Thank you!

Rudy

===

class A
{
void f(double& d){}

void g()
{
double d;

cout << &d; // "0x0012fac8"

f(d);

cout << &d; // "0x0012fe10" (== 0x0012fac8 + 420)
}
}

void main()
{
A a;
a.g();
}
 
Sounds like they're calling a function that messed with the stack pointer.
Look for use of alloca or longjmp, to name a couple of suspects.

-cd
 
Hi Carl, thanks for your quick reply.

How could messing with the stack pointer change the address of a local
variable? Are local variable addresses related to the value of the stack
pointer?

I thought in assembly, local variables addresses were simply "constants" and
could not be manipulated by fiddling with the stack pointer.

I would verify this by looking in the MSVC assembly debug output, but local
variables are prined there by "name", not by value. For example, this is
the assembly displayed that pushes the address of "d" onto the stack:
00411C67 lea eax,[d]
00411C6A push eax

Thanks,

Rudy
 
Local variable addresses are fixed offset from the stack pointer (esp) , or
the "activation frame" pointer (ebp). If the called function clobbered ebp,
for example, your local variables would appear to move.

-cd
Hi Carl, thanks for your quick reply.

How could messing with the stack pointer change the address of a local
variable? Are local variable addresses related to the value of the
stack pointer?

I thought in assembly, local variables addresses were simply
"constants" and could not be manipulated by fiddling with the stack
pointer.

I would verify this by looking in the MSVC assembly debug output, but
local variables are prined there by "name", not by value. For
example, this is the assembly displayed that pushes the address of
"d" onto the stack: 00411C67 lea eax,[d]
00411C6A push eax

Thanks,

Rudy

"Carl Daniel [VC++ MVP]"
Sounds like they're calling a function that messed with the stack
pointer. Look for use of alloca or longjmp, to name a couple of
suspects.

-cd
Click to expand...
Click to expand...
 
Rudy Ray Moore said:
[...]
The address of local variables change when they are passed to another
function by reference (or when their addresses are passed). The address of
the variable increases by 420 bytes.
[...]
Click to expand...

This:

// ----8<----8<----8<----8<----8<----8<----8<----8<----8<----
#include <iostream>

class A
{
public:
void f(double&){}

void g()
{
double d;
std::cout << &d << std::endl;
f(d);
std::cout << &d << std::endl;
}
};

int main()
{
A a;
a.g();
}

// ---->8---->8---->8---->8---->8---->8---->8---->8---->8----

Compiling...
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
cl /Od /I "..\.." /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /Gm /EHsc /RTC1 /MTd /GS /Za /Zc:wchar_t /Zc:forScope /GR /W4
/c /Wp64 /Zi /TP /Bt
\Develop\test.cpp
test.cpp
Linking...
Test - 0 error(s), 0 warning(s)

produces this:

0012FEB8
0012FEB8


on my machine.
Seems to be something on your end.

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers
 
Hi Hendrik,

Thanks for you interest. That particular sample works for me too. The case
that produces that problem is actually quite complicated and can't be posted
to the group. I was hoping that that example would just shed some light on
the kind of problem I am experiencing.

Rudy


Hendrik Schober said:
Rudy Ray Moore said:
[...]
The address of local variables change when they are passed to another
function by reference (or when their addresses are passed). The address of
the variable increases by 420 bytes.
[...]
Click to expand...

This:

// ----8<----8<----8<----8<----8<----8<----8<----8<----8<----
#include <iostream>

class A
{
public:
void f(double&){}

void g()
{
double d;
std::cout << &d << std::endl;
f(d);
std::cout << &d << std::endl;
}
};

int main()
{
A a;
a.g();
}

// ---->8---->8---->8---->8---->8---->8---->8---->8---->8----

Compiling...
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
cl /Od /I "..\.." /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /Gm
Click to expand...
/EHsc /RTC1 /MTd /GS /Za /Zc:wchar_t /Zc:forScope /GR /W4
 
Hi Hendrik,

Thanks for you interest. That particular sample works for me too. The case
that produces that problem is actually quite complicated and can't be posted
to the group. I was hoping that that example would just shed some light on
the kind of problem I am experiencing.
Click to expand...

It could be stack corruption, due to a bug in your code (such as using
a pointer to a stack based object that has gone out of scope).

Tom
 
Rudy Ray Moore said:
Hi Hendrik,

Thanks for you interest. That particular sample works for me too. The case
that produces that problem is actually quite complicated and can't be posted
to the group. [...]
Click to expand...

You'll have a pretty good chance to find the
bug while trying to reduce the code to a
minimal sample that reproduces the error.
And if you don't find it that way, you have
a very good chance that a repro case will
allow others to find it here.
Rudy
[...]
Click to expand...


Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers
 
Back
Top