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;
GetTrackDropPar ms(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::GetT rackDropParms (0BC1830h)

[Chris Stankevitz]

"Carl Daniel [VC++ MVP]" <cp************ *************** **@mvps.org.nos pam>
wrote in message news:%2******** *********@TK2MS FTNGP12.phx.gbl ...

Should changes in ESP be visible in the "disassembl y" view?
Yes, it's visible in the Registers window along with all the others.
Debug|Windows|R egisters 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]

"William DePalo [MVP VC++]" <wi***********@ mvps.org> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..

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++]]

"Chris Stankevitz" <ch******@stank evitz.nospample ase.com> wrote in message
news:ui******** ******@TK2MSFTN GP09.phx.gbl...

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