Get madExcept and it will tell you exactly what is happening at the time of the fault. You ll see the full stack, and particularly where it is running away.

You should REDUCE the stack size in linker options. Then run it under the debugger and hopefully the problem will show up without your having to wait two hours.

I d almost say: run it in the debugger ;^)

What I used to do is add a enter and leave log function in every method. With the proper indentation I could trace in the log the callpath.

When a stackoverflow would occur it would really be visible in the log since the indentation level should be through the roof

 void someMethod()
 {
      logMethodEnter("someMethod");

      ... do stuff...
      log("something")
      ... do stuff...

      logMethodLeave("someMethod");

 }

the logger would keep track of current logdepth and log stuff like this:

 >someMethod
   something
 <someMethod

Do you have the IDE installed on the test machine? If so, try to reproduce the problem from within the IDE. When the stack overflow occurs, look at the Call Stack (View->Debug Windows->Call Stack). It will probably have the same function being called many times, like this:

FunctionA
FunctionB
FunctionA
FunctionB
FunctionA
FunctionB
...

If you see that, then you know that these functions are calling each other without ever concluding.

If you don t have the IDE installed on the test machine, then you can still do this via remote debugging. If you provide a little more information about your scenario we may be able to help more.

Specifically it might be helpful to know:

• Can you reproduce it?
• Is the IDE installed on the test machine?
• What version of Delphi?

You can increase the stack size using the project linker options or the $M compiler directive, but I don t think it wil solve the problem unles the stack is really small.

If you run the application in the debugger, it will break at the exception eventually.

If you are using a thread(not main ex:sock connection) and main thread so they share the same stack. Solve this way :just create a thread with its own stack for each connection.

Problem > each call you do it call stack for frame (the shared one so big problem) example you call proc aa(a,b:integer) for example on calling always the same function or different one ;

You have a socket thread running, and onconnect you call proc a; and stays doing something it take 5 secs.

if some one connects before the on connect close connection (release stack). You have the 2 connected clients (2 diff stack frames with each different data)

stack

push a,b (integer); Values 5,10 - from 1 conn

push a,b (integer); Values 7,3 - from 2 conn

if the onconnect call the functions a(5,10) and stays doing something for about 5 sec. and some one connect to the server socket again it call on connect again.

The stack olds the first call frame yet didn t went out of proc. So didn t pop a,b from (5,10)

It is more complex than this if you proc call again then it will override data on the 2 frame (local proc variable of 2 connection) so when 2 connection get data from stack is already overridden by other info for sure. so it will do incorrect behavior.

When first connection is down will pop a,b but 7,3 (from second connection) and not the 5,10 it saved. so it will stack overflow not on the moment but later with the program running and stack release errors you ll get eventually a $FFFFFFFF $SP stack. so it will try to $FFFFFFAA when you call a function so is bigger than ya stack ex: $M 65536 and not 4 gigabytes as $FFFFFFAA.