I have code that seems to have always worked until I tried it in a
particular situation in a catch-block, although even this situation looks
out of the ordinary, since it works fine in another catch-block. The service
crashes with EXCEPTION_STACK_OVERFLOW and the stack always points to the
same non-recursive function (or rather it opens an .ASM file dealing the
guard page and then it is always the same function). I ran the case in the
catch-block that did not cause this exception in the debugger and then it
did - in exactly the same place - and it continues to run fine outside the
debugger. The difference between the two cases is that in the first one the
object goes out of scope (before it reaches the catch-block) and then, once
a particular condition is detected, is re-created when the code returns to
the scope (while (service-is-running) try { X x; ... } catch (Y) {
disconnected ? make another turn; }) whilst in the second it is not
destroyed but rather manipulated through functions that cause
re-initialisation. In the debugger, the file with the guard page is opened
as soon as the function that appears at the top of the stack is entered.
The code is not particularly interesting but it should be noted that quite a
few functions are called and some of these in turn have their own
try-and-catch blocks inside them. It may well be that the number of
variables created along the way will consume the stack, although for that to
happen, I suspect, the stack that an application has when running inside a
catch-block should be smaller than usual, and it is this that I would like
to confirm. If the stack is smaller, is there way to find out how big it is
and how close I am to the limit?
Thank you.
Paul