1

Hi I am getting the runtime error:

"Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention."

I know there is a question already present in stackoverflow on the same topic.

But my doubt is that what is meant by "ESP" here.

In my code: I am calling a function X() like this:

obj -> X();

But I observe in call stack that some other function Y() which is NOT EVEN a part of the current solution is getting called!!!! (I did F11 on the statement "obj -> X(); " and control is going inside Y(), and this Y() is not even a part of my current SOLUTION !!!!!!!!

This is so strange that when I am calling X() some other function Y() (NOT even a part of the current solution) is getting called.

Can anyone kindly help me in this....
FYI I am using VS2008.

Thanks in advance.

codeLover
  • 3,720
  • 10
  • 65
  • 121
  • This is a common diagnostic for DLL Hell. The declaration of the class doesn't match its implementation. You left too few breadcrumbs to guess how this happened. – Hans Passant Mar 24 '12 at 14:37
  • http://stackoverflow.com/questions/8626160/run-time-check-failure-0-the-value-of-esp-was-not-properly-saved-across-a-fun – Lakshman Rao Jun 23 '16 at 13:05

2 Answers2

3

"ESP" is the stack pointer.

Roughly, after a function call the stack pointer should be same as before. The run time check that's triggered indicates this doesn't hold true.

Now, that's the symptom. The cause is usually somewhere else, most likely in your code that's executed before.

Note that after ESP is corrupted, the information given on your call stack is not reliable anymore. So Y() out there might be just another symptom. (there are other possible reasons, I would just ignore that fact for now.)

Common/possible causes for stack pointer corruption:

  • you are calling a function with a different calling convention than it's implemented

    • are you calling a function through a function pointer, and do you have to force a cast at some point to make it compile?
    • are you calling a method in an external DLL?
    • are you messing around in another way with calling conventions (cdecl, stdcall etc.?)

  • Corrupting the virtual method table (VMT) of an object, calling different yet "reasonable" code

    • is X() virtual?
    • could be triggered by an out of range access that overwrites a VMT, though that is not very likely to lead to these symptoms
    • check for correct initialization order (e.g. initializing a base class reference with a derived class member, calling virtual methods in the constructor, stuff like that.)
peterchen
  • 40,917
  • 20
  • 104
  • 186
  • I am calling the function X() with an interface pointer Iptr & ofcourse this interface "Iptr" has the function x() in it. --> Yes x() is VIRTUAL. Also I am not getting any clue why is this error coming. I checked everything in my code is correct. Can u kindly hlep by providing some more inputs on this. Thanks. – codeLover Mar 26 '12 at 09:41
  • You are likely thrashing your VMT, or you doing something undefined. Reduce the code, until you have a minimal reproduction, or put in extra calls to obj->X() to track down the location where you introduce the mistake. (If you can work your debugger, you can also look up how your compiler implements VMT's and set data breakpoints.) – peterchen Mar 26 '12 at 10:30
1

Well, since ESP is the stack pointer, strange behavior is expected.

Run-Time failures are hard to debug. They can be cause by memory corruption, a failed or incomplete compilation/linkage, code that leads to undefined behavior, failure to return from a function that declares a return type, etc.

Try rebuilding the solution and stepping through the code in dissasembly mode. That might give you a clue.

Luchian Grigore
  • 253,575
  • 64
  • 457
  • 625
  • I tried rebuilding the solution, restarting VS, restarting Windows etccc.. No use. Still facing the same issue. Some more inputs on this will be helpful. Thanks. – codeLover Mar 26 '12 at 09:42
  • @engineerMaster sadly, these kind of errors are hard to track down even if you have the code in front of you. Try a memory debugger. – Luchian Grigore Mar 26 '12 at 09:44