Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 780
  • Last Modified:

what is ESP error !!! in VC++ Debug Mode !!

Debug Error !
 
 Modle :
 file  : i386\chkesp.c
 Line  : 42
 
 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 am programming Server Program..

When Clients Number is small, ESP Error not occured..

but When Large, ESP Error!!!!..

I don't know what is problem ???..

Calling convention is correct ...

I don't know ESP Error..????..

Is there any method skip ESP error in Debug Mode ????..

0
jhjeon
Asked:
jhjeon
  • 6
  • 2
  • 2
  • +4
1 Solution
 
jkrCommented:
Sounds like a stack overflow to me...
0
 
nietodCommented:
ESP is the "Extended (which you can ignore) Stack pointer" register   In other words, it is a register in the CPU that stores a pointer to the top of the CPU stack.

The CPU stack is somewhat like the stacks you (probably) have learned about in programming.  It is a LIFO "container".  That is the last think placed on the stack in the first thing to be removed.     However a CPU stack stores binary data of essentually any tiype and size--unlike a typical stack container.    The CPU stack is used primarily for storing procedure's (non-static) local variables, parameters, return values, and return addresses for calling procedures.

The C++ compiler is responsible for creating machine code that manages the stack.  When a procedure is called,the parameters are pushed onto the stack, then  the calling procedure's address next instruction is placed on the stack, then the procedure is called.   The calling procedure can access the parameters as needed, when it is done it removed the parameters from the stack and removes the stored return address and returns execution to that return address   (The exact details vary, but that is a typical idea.)

continues
0
 
nietodCommented:
A stack problem typically occurs when the calling and the called function do not agree on the number and size of the parameters, or in how the parameters are to be passed ( like stdcall vs cdecl).  In this case, the called function might look for the return address at the wrong location and thus return to the wrong location.   Or it might not remove all the parameters from the stack, or remove too much.   There are lots of possible errors of this type.

You might look to see if you have a case where you are calling a function via a pointer (like a DLL function loaded with GetProcAddress())   Or if you are providing a function that someone else is calling via a pointer.    These are instances where you can run into these problems.  If you declare the function to use the wrong calling convention or wrong parameters or return value, the stack can get messed up.    (Ussually this is not a problem, because if you have this type of mismatch with a regular function call the compiler will detect it and report it as a compiler error.  But if you try this through a pointer, you can use cast you can circumvent the error and allow the code to compile and then work wrong.)
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
nietodCommented:
I should mention "calling conventions" are the rules that govern the procedures for calling and returning from functions.  They specify the order in which parameters are placed on the stack (and/or registers) and who is responsible for removing the parameters)

In C++ on win32 there are two main calling conventions.  There is "standard call" (__stdcall) and "C-declaration" (__cdecl).      You can look these up in the VC help for more info.

when a function is called, the caller must know (or think it knows) what calling convention the called function uses.  This way they can agree on how to pass parameters etc.   If they don't agree and the code is still forced to compile, then you will get a stack errror.
0
 
jkrCommented:
>>I should mention "calling conventions" are the rules that govern the ...

You are right, but

>>When Clients Number is small, ESP Error not occured..
>>but When Large, ESP Error!!!!..

If the callconv was wrong, not a single call could have succeeded...
0
 
nietodCommented:
I missed that.  That is true.

But on win32 the stack is supposed to grow as needed (within reason) so it takes an extreme case of overuse to overflow a stack (Other than infinite recursion).

There has to be a little more to the storey than that, right?
0
 
jhjeonAuthor Commented:
I make Client class...

Storage size of client is about 50000 byte

Storage structure is array..(reciving Queue buffer)
and Some Pointer buffers Etc.(Sending Buffer,
Maximum sending buffer is 999 pointers)

server program supprots 1000 clients (in array)

1000 x 50000 = about 50M..

my system memory is 128M...

ESP error is concerned with System Stack ?
0
 
AxterCommented:
Why don't you try using std::vector instead of a C-Style buffer.
0
 
pjknibbsCommented:
nietod: I don't think that's actually true--on UNIX the stack is automatically resized to accommodate a program's needs, but not on Win32. I know this because I've had to convert a UNIX utility to a Win32 command-line application, and I had to modify it to use malloc()'ed memory rather than the huge local arrays it WAS using because of stack size limitations. (Sure, I could have boosted the size of the stack in the linker, but I thought defining a two hundred thousand entry local integer array was sloppy programming anyway!).
0
 
jhjeonAuthor Commented:
um..ESP Error...

is it memory Problem....??

not calling convention problem..?
0
 
AxterCommented:
>>is it memory Problem....??

It's a memory handling problem, and an alternate method of handling your memory could fix the problem.

One method that should fix the problem, is using memory mapping vi Map API's.

See:
CreateFileMapping, OpenFileMapping, MapViewOfFile, and UnmapViewOfFile.
0
 
nietodCommented:
>> Why don't you try using std::vector instead of a C-Style buffer.
Because it will use less memory?    Actually it will use at least as much, probably more.    The only advantage woudl be if the array size is declared larger than it needs to be and the vector wouldn't grow as much.    But there is no evidence of this--at least not yet.

>>  I don't think that's actually true--on UNIX the stack is
>> automatically resized to accommodate
>> a program's needs, but not on Win32.
Its definitely a feature of the x86 chips and I am fairly certain the OS is using it.

>> I've had to convert a UNIX utility to a Win32
You can always specify a larger stack size to the linker.    AFAIK this is the initial stack size, and it will grow from there.

>> Sure, I could have boosted the size of the stack
>> in the linker, but I thought defining a two hundred
>> thousand entry local integer array was sloppy
>> programming anyway!).
defining it as a dynamic array isn't really any different.

>> s it memory Problem....??
>> 
> not calling convention problem..?
In this case it is a memory problem.  You are probably running out of memory on your stack.   For the short term you could try increasing your stack size.

Go to the project settings dialog  (project menu)
Link page tab.
Output category
and fill in a the stack size option.    Try a larger value, like 60M.


In the long term, you need to really reconsider your memory ussage.  Its very likely that your program can be using memmory much more effectively than it is currently.   (Maybe)      But we can't really help you with that unless we know more aout what it is doing with these huge arrays/data structures.
0
 
pjknibbsCommented:
nietod: I think it's actually the other way round--my reading of the MSDN (and my experience with the program I mentioned, which crashed with a stack fault exception) is that the reserved stack size in the linker is the MAXIMUM possible size for the stack, not the minimum. Certainly the MSDN documentation on the STACKSIZE module definition statement says that the "reserve" number is the amount of virtual address space reserved for the stack in an .EXE.
0
 
nietodCommented:
Opps.  you could be right.   I'll have to look into that.    Not now though.
0
 
griesshCommented:
Dear jhjron

I think you forgot this question. I will ask Community Support to close it unless you finalize it within 7 days. You can always request to keep this question open. But remember, experts can only help you if you provide feedback to their questions.
Unless there is objection or further activity,  I will suggest to split between

     "jkr & nietod"

comment(s) as an answer.

PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
======
Werner
0
 
MindphaserCommented:
Force accepted

** Mindphaser - Community Support Moderator **

nietod, there will be a separate question with points for your help.
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 6
  • 2
  • 2
  • +4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now