 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / June 2005Does this VC.net dissasembly look right?
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) 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 >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 [quoted text clipped - 20 lines] > 0161098D mov ecx,dword ptr [this] > 01610990 call CtTracker::GetTrackDropParms (0BC1830h) > 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 > 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 >> 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 [quoted text clipped - 11 lines] > 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 > 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 >> What version of the compiler are you using? Can you describe the >> taxonmy and structure of the CtTracker class and the class where the [quoted text clipped - 11 lines] > 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. > [quoted text clipped - 3 lines] > 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 >> 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. 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 > Stack corruption is usually the result of one of the following: > [quoted text clipped - 3 lines] > 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 > assert(MyClass::GetMySize() == sizeof(MyClass)); Excellent debugging tool, thanks for the suggestion! Chris > 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 > 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 [quoted text clipped - 3 lines] > 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 > 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.