Does this VC.net dissasembly look right?

[Chris Stankevitz]

I declare two variables and call a function. The second to last statement
seems fishy to me. My other non-static function calls to other methods in
the same class do not have "this" line. Furthermore, after executing this
line, the addresses of my local variables change.

Is this normal?

Thanks,

Chris

===


int Ni;
double dt;
GetTrackDropParms(Track, dt, Ni);
01610981 lea ecx,[Ni]
01610984 push ecx
01610985 lea edx,[dt]
01610988 push edx
01610989 mov eax,dword ptr [Track]
0161098C push eax
0161098D mov ecx,dword ptr [this]
01610990 call CtTracker::GetTrackDropParms (0BC1830h)

 

[Chris Stankevitz]

I take back what I said about not seeing "this" line in other non-static
calls to methods in the same class.

Nevertheless, when "this" assembly instruction is executed, the addresses of
local variables change. Why is that happening?

Chris

 

[William DePalo [MVP VC++]]

Nevertheless, when "this" assembly instruction is executed, the addresses
of local variables change. Why is that happening?

Well, if it is a real problem it could be stack corruption. Less likely is
debugger weirdness. Can you pare the problem down to some small, compilable
snippet that you can post here?

Regards,
Will

 

[Chris Stankevitz]

Well, if it is a real problem it could be stack corruption. Less likely is
debugger weirdness. Can you pare the problem down to some small,
compilable snippet that you can post here?

Regards,
Will

Thanks for the reply Will,

The application is a large (1 million lines) simulation. I'm unable to
shrink it down.

Can someone recommend ways to go about debugging "stack corruption"? I have
lots of time, so I'd be happy with even tedious ways. I just want to figure
out what is going on.

Thanks,

Chris

 

[Carl Daniel [VC++ MVP]]

Thanks for the reply Will,

The application is a large (1 million lines) simulation. I'm unable
to shrink it down.

Can someone recommend ways to go about debugging "stack corruption"? I
have lots of time, so I'd be happy with even tedious ways. I just
want to figure out what is going on.

Stack corruption is usually the result of one of the following:

- Over-indexing a local varaible (array). Compiling with /RTCsu (VC7+)
should catch this kind of error.
- Calling a function through a function pointer of the wrong type (e.g.
calling a __stdcall function through a __cdecl pointer will remove the
parameters from teh stack twice).

I have seen cases in the past (VC6) where the debugger does not show member
variables correctly when executing in a virtual member function that was
originally declared in a non-leftmost base class (i.e. in a situation where
there's a 'this-pointer adjustment' in effect - the debugger is apparently
unaware of the adjustment).

What version of the compiler are you using? Can you describe the taxonmy
and structure of the CtTracker class and the class where the call appears
(if I follow what you've posted correctly, you're calling one non-static
member function from another)?

Make sure you're not seeing debugger wierdness - it does happen. Write some
local variables out to the console or to OutputDebugString before and after
the call in question and verify that the values do appear to change.

-cd

 

[Chris Stankevitz]

What version of the compiler are you using? Can you describe the taxonmy
and structure of the CtTracker class and the class where the call appears
(if I follow what you've posted correctly, you're calling one non-static
member function from another)?

Thanks for your help. It's not debugger weirdness.

Version: VC .net 2003 7.1
Microsoft Visual C++ .NET 69462-270-0000007-18536

CtTracker inherits from one other class. No multiple inheritance, so there
isn't "multiple inheritance" kind of 'this-pointer adjustment'. Neither
function is virtual so there is no "non-leftmost" issue, although to be
honest I don't understand that. Neither function is static.

I suspect I'm stomping on memory somewhere in the "past". I ran the case
through Rational Purify hoping to detect the stomping, but came up empty. I
will try compiler option /RTCsu with which I am presently unfamiliar.

Let me ask this question:How do I determine if stack corruption is taking
place?

Possible answer:
Watch register ESP. If it changes while stepping through a function, you've
got stack corruption.

Possible follow up question:
Should changes in ESP be visible in the "disassembly" view?

etc. etc.

Another possible question:
I understand local variables are offsets to the stack frame pointer. How
can I see these offset values? I would like to verify that they are not
changing while the function is executing. Disassembly does not show the
offset values (I think).

This is the "systematic" way I would like to go about solving this problem
(I think).

PS: When my local variable addresses change, ESP does not change.

Thanks again for your help!

Chris

 

[Tamas Demjen]

Stack corruption is usually the result of one of the following:

- Over-indexing a local varaible (array). Compiling with /RTCsu (VC7+)
should catch this kind of error.
- Calling a function through a function pointer of the wrong type (e.g.
calling a __stdcall function through a __cdecl pointer will remove the
parameters from teh stack twice).

I'd like to add one more case when two compiled modules are not byte
compatible. For example:

- Borland treats enums as single bytes by default, while other compilers
treat them as ints (4 bytes).
- Different structure packing alignment was used when compiling a
particular module (the default pragma pack was different for a DLL).
- Some class members in the header file may have been inside an #ifdef
(such as #ifdef _DEBUG), which was defined while compiling your DLL, but
not when compiling your main app.

I've experienced all 3 of the above problems, all of which can (usually)
be detected by comparing sizeof(T)'s. Example:

// In DLL
class MyClass
{
public:
static int GetMySize() const;
}

// to .cpp (make sure it's not inlined)
int MyClass::GetMySize() const
{
return sizeof(MyClass);
}

// In EXE
assert(MyClass::GetMySize() == sizeof(MyClass));

Your stack can be corrupted when you pass a local variable to a function
by pointer or by reference, and there is a sizeof mismatch.

Tom

 

[Carl Daniel [VC++ MVP]]

"Carl Daniel [VC++ MVP]"

What version of the compiler are you using? Can you describe the
taxonmy and structure of the CtTracker class and the class where the
call appears (if I follow what you've posted correctly, you're
calling one non-static member function from another)?

Thanks for your help. It's not debugger weirdness.

Version: VC .net 2003 7.1
Microsoft Visual C++ .NET 69462-270-0000007-18536

CtTracker inherits from one other class. No multiple inheritance, so
there isn't "multiple inheritance" kind of 'this-pointer adjustment'.
Neither function is virtual so there is no "non-leftmost" issue,
although to be honest I don't understand that. Neither function is
static.

Non-leftmost refers to the order of inheritance in a multiple inheritance
case. No MI - no non-leftmost bases.

I suspect I'm stomping on memory somewhere in the "past". I ran the
case through Rational Purify hoping to detect the stomping, but came
up empty. I will try compiler option /RTCsu with which I am
presently unfamiliar.
Let me ask this question:How do I determine if stack corruption is
taking place?

It's hard.

Possible answer:
Watch register ESP. If it changes while stepping through a function,
you've got stack corruption.

ESP or EBP or the contents of the stack itself could be modified. Normally,
it's the contents of the stack that get modified, then on returning from a
function, an incorrect value of EBP gets picked up off the corrupted stack,
followed shortly by fireworks as your program blows holes in itself.

Possible follow up question:
Should changes in ESP be visible in the "disassembly" view?

Yes, it's visible in the Registers window along with all the others.
Debug|Windows|Registers from the menu or Ctrl-Alt-G from the keyboard if the
reigsters window isn't visible.

etc. etc.

Another possible question:
I understand local variables are offsets to the stack frame pointer. How
can I see these offset values? I would like to verify that they
are not changing while the function is executing. Disassembly does
not show the offset values (I think).

The offsets are hard-wired into the code by the compiler, and may change
from point to point depending on calling patterns and optimization level.
Normally, in debug builds, all locals are accessed using offsets from EBP
and those offsets are fixed. However, in an optimized build, the compiler
may choose to not use EBP and reference variables directly off ESP. In this
case, the offset to a variable might be different at two points in a single
function if the compiler has pushed parameters for a function call, or
spilled temporary values to the stack. The compiler keeps track of
everything it's put on the stack at each point and will generate the correct
offset(s), but it can make the disassembly a bit hard(er) to follow.

This is the "systematic" way I would like to go about solving this
problem (I think).

PS: When my local variable addresses change, ESP does not change.

How do you conlucde that the address changes?

Are you debugging an optimized build, or a debug build?

-cd

 

[William DePalo [MVP VC++]]

Can someone recommend ways to go about debugging "stack corruption"? I
have lots of time, so I'd be happy with even tedious ways. I just want to
figure out what is going on.

Well, if you have _lots_ of time, and if the local variables are smallish,
you might want to put a few of them in the watch window. Use addresses
rather than names because names go out of scope. Then put breakpoints at
entry to each of the functions you suspect on the way from their last good
location to the place where they change. That should get you the function.
Once you find it, step through it a line at a time. That should get you the
location.

You don't actually need to set the breakpoints. Just single step into your
code from the last known good location. At a line or two into a function
just choose "step out".

By the way, are you using any of the C runtime functions like memcpy() and
strcpy() and their cousins? They are notorious! :-(

Regards,
Will

 

[Chris Stankevitz]

Yes, it's visible in the Registers window along with all the others.
Debug|Windows|Registers from the menu or Ctrl-Alt-G from the keyboard if
the reigsters window isn't visible.

That wasn't quite my question, although the point is moot since ESP is not
changing in my case. What I was trying to ask was "What should one think if
ESP changed, but the corresponding assembly instruction did not reference
ESP? Is that even possible?"

How do you conlucde that the address changes?

Watch window before F10:
dt = 100.0
&dt = 0x8812ab12 (Notional)

Watch window after F10:
dt = 3.12124554e-300
&dt = 0x125484ba (Notional)

Results consistent with small value of dt. More on that below.

Are you debugging an optimized build, or a debug build?

unoptimized "debug" build.


There have been two important developments in the case. As I was trying to
make screenshots to illustrate the example I produced above, I found...

1. the bad behavior (local var addresses changing [LVAC]) stopped.
Yesterday it was repeatable, but not today.

2. I had a logic error which led me into the debugger and to the LVAC issue.
It may have be that LVAC is just a "debugger" issue. My logic error
produced results consistent with a very small value of dt - which further
convinced me that LVAC was really happening.

I should have (and next time I will):
cout << &dt << endl;
f();
cout << &dt << endl;

Thanks a million for your help guys,

Chris

 

[Chris Stankevitz]

assert(MyClass::GetMySize() == sizeof(MyClass));

Excellent debugging tool, thanks for the suggestion!

Chris

 

[Chris Stankevitz]

Well, if you have _lots_ of time, and if the local variables are smallish,
you might want to put a few of them in the watch window. Use addresses
rather than names because names go out of scope. Then put breakpoints at
entry to each of the functions you suspect on the way from their last good
location to the place where they change. That should get you the function.
Once you find it, step through it a line at a time. That should get you
the location.

Excellent tip and I did just that. I found that the values [typing
addresses in the watch window] did not change. However, the values [typing
variable names in the watch window] did change. This was consistent with
"local variable addresses changing" [LVAC]

By the way, are you using any of the C runtime functions like memcpy() and
strcpy()

This is a huge application and there's no doubt that dangerous functions
such as these are being used.

Thanks for your help,

Chris

 

[William DePalo [MVP VC++]]

Excellent tip and I did just that. I found that the values [typing
addresses in the watch window] did not change. However, the values
[typing variable names in the watch window] did change. This was
consistent with "local variable addresses changing" [LVAC]

Have you found the line where things go bad? Can you post it here?

Thanks for your help,

You are welcome.

Regards,
Will