Running down a 'stack overflow' bug

Question

I have an application written in Delphi W32 that is in beta.

On the test PC, it haphazardly kicks out a 'stack overflow' message after a few hours of use.

How can I trap the error and find the cause?

Can I increase the Stack size?

Answer 1

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

Answer 2

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.

Answer 3

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?

Answer 4

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.

Answer 5

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.

Answer 6

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

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

U have a socket thread runnin, and onconnect u call proc a; and stays doin something it take 5 secs.

if some one conects before the on connect close connection (release stack). U have the 2 connected clients (2 diff stack frames with each diffrent 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 didnt went out of proc. so didnt pop a,b from (5,10)

It is more complex than this if u 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 overidde by other info for sure. so it will do incorrect behavior.

When 1st connection is down will pop a,b but 7,3 ( from 2nd connectin ) and not the 5,10 it saved. so it will stack overflow not on the moment but later with the program runnin and stack release errors u'll get eventually a $FFFFFFFF $SP stack. so it will try to $FFFFFFAA when u call a fucntion so is bigger than ya stack ex: $M 65536 and not 4 gigabytes as $FFFFFFAA.