Run-Time Check Failure #0 - The value of ESP was....

Do you know what function is causing the problem? Also, are you familiar with what a stack frame is? It looks like analyzing this may help solve the problem. I'm pretty sure you can do this with the Visual Studio debugger.

also, i stepped through the code with the debugger, and it seems this is happening either on the line that main returns, or after main returns...

Quote:

Original post by Omnibus Do you know what function is causing the problem? Also, are you familiar with what a stack frame is? It looks like analyzing this may help solve the problem.

sorry, what is the stack frame exactly?

thanks again in advance.

also, if i hit "continue", it brings me to this line, inside the file "crt0.c"

#else  /* WPRFLAG */            __initenv = _environ;            mainret = main(__argc, __argv, _environ);#endif  /* WPRFLAG */

it says that the third line in that ('mainret = ...') would be the next line of code to be executed.

Quote:

Original post by graveyard filla sorry, what is the stack frame exactly?

It's the data structure built in memory when you're calling a function, including the local variables, the function parameters, the address it returns to when you're done...

You always hear people of variables being 'on the stack', well, stack frames are the entities held by the stack :)

When you call a function, space is allocated on the stack in memory for the parameters and the function's local varables. The %esp register is used to store the address of the top of the stack. The stack frame is basically the area on the stack for the function that you are in. I'm not exactly sure what is going on here so I could be way off. It's just the first thing that comes to mind when the error says something about esp and a function call.

What is the library that you're using?
See my vast reply on this topic for a bit of background on the stack - the stack frame is what's visible to the current function.
Also, have you tried doing a Rebuild All?

Quote:

Original post by graveyard filla also, if i hit "continue", it brings me to this line, inside the file "crt0.c" #else /* WPRFLAG */ __initenv = _environ; mainret = main(__argc, __argv, _environ);#endif /* WPRFLAG */ it says that the third line in that ('mainret = ...') would be the next line of code to be executed.

Actually, the next statement to be executed is the assignment of mainret from the return value of main(). Is your main() function too large to post? It seems that you're calling a function in main() (not a function in a function in main, or else you'd hit the check sooner) which is screwing up the stack somehow.

thanks everyone for your replies.

after some debugging, i found the function that was causing me problems.. when i comment out this function call, then everything works fine. and Steve was right, this function is being called from main()..

its weird though, like i said, im not using any function pointers, im calling the function directly. i dont have access to the actual source, only to the declaration.. the library is a proprietary library for a commercial app im working on. the docs are very bare, theres no support forum, and my boss is very busy (not to mention hes pushing me to get this finished ASAP), and knows less about this API then i do anyway [grin]. i haven't signed an NDA yet, but i still don't want to post any code. this is what the function declaration looks like:

void FAR PASCAL FuncName( LPSTR paramname );

where FAR is #defined as far, and PASCAL is #defined as __stdcall.

maybe theres something obvious here that i don't see? anyone have any clues why this might be happening?

thanks for any help.

FAR!! I thought the need for such concepts as far and near were abolished with the introduction of the protected memory models in 32 bit architectures. Someone please correct me if Im wrong but I believe that using the far keyword implicitly (that is by definition) requires that your function is using a [far] pointer. The far keyword is used for functions or variables which are not in the same [memory] segment as the caller. The fact that the function uses far in its declaration must mean that the function address is accessed by use of a far pointer, as would be the case of a DLL? But this might not be the case at all, it could be a case of clashing calling conventions.

What is the calling convention of your project or function? I believe the default is __cdecl as opposed to __stdcall, perhaps calling that function [FuncName] from one with a similar convention could help? Since __cdecl pushes variables into the stack in an opposite manner (reads in values in an opposite manner) of __stdcall. By the way, is that some kind of 16bit DLL you are using or something?

Heya,

My two cents. I've had this problem a while myself, though usually through fault of my own code.

The assembly esp value points to the position on the stack that memory is allocated up to. When you call a function that takes 12 bytes of parameters, you get esp = esp-12. When the function returns you get esp = esp+12. At least, when you're using stdcall.

We had some issues with a statically linked lib causing this whenever any function was being called with it. Never actually found out the cause, but we assumed that it had something to do with the lib somehow out of sync with the application, because as soon as it was recompiled, everything worked again.

Maybe overwrite your lib file with a freshly downloaded / a backup copy of it, and try that...

Oh, and failing that, you could always just restore the state of ESP yourself... [though it'd definitely be a Bad Thing to do, it might get everything working]

int tempEAX;
__asm{ mov tempEAX, esp };
//function call
__asm{ mov esp, tempEAX };

or something like that [no compiler and months since I last wrote anything even remotely to do with assembly]...

CJM

Oh, above post assumes that it was working and then one day suddenly decided to break itself, rather than the library breaking it.

Otherwise, look for a new version of the library, or try other calling conventions on it, like fastcall, or whatnot.

CJM

This error is most often caused by mismatching header (*.h) and library (*.lib, *.dll) files. It tells you that you have called a function with another signature as the compiled function expects.

Here's an example which causes this exact error:


So check for outdated library files, include path search order (maybe it finds a newer version of some library headers but you're still linking against the older one) and that your project doesn't have old binaries left over somewhere which are being used accidently.

-Markus-

hi everyone,

thanks for your replies. i downloaded the latest version of the library, and it works now! thanks a lot for your help and suggestions.