Debugging stack overflows..

[Søren Johansen]

Hi,

I am getting a stack overflow exception. I was wondering how to to debug
this situation with vc.
I know that the problem is not based on (unintended or intended) recursion
and the call stack at the time of the exception is rather small. Thus, there
must be some variable declared on the stack that takes up a lot of memory.
How can I find this? I thought about setting a data-breakpoint in the end of
the stack but I don't know what this address would be.

Søren

 

[Serve Laurijssen]

Hi,

I am getting a stack overflow exception. I was wondering how to to debug
this situation with vc.
I know that the problem is not based on (unintended or intended) recursion
and the call stack at the time of the exception is rather small. Thus, there
must be some variable declared on the stack that takes up a lot of memory.
How can I find this? I thought about setting a data-breakpoint in the end of
the stack but I don't know what this address would be.

If it's reproducable, just put a breakpoint at the beginning of the function
and track all automatic variables that are created. A class with many value
members can also be a problem.

class {
public:
char a[1000000];
}

 

[Søren Johansen]

If it's reproducable, just put a breakpoint at the beginning of the
function

and track all automatic variables that are created. A class with many value
members can also be a problem.

class {
public:
char a[1000000];
}

Well it is (reproductable), but the final function called does not allocate
major variables. In fact, I don't see any of the functions on the call stack
with any variables of significance. Which is why I think that you are
right - there is a class somewhere that contains some large member. But how
can I track this sort of thing down?

 

[Jim Delany]

Go into the exceptions menu item under debug and change stack overflow to
stop always. Press run and you should be sitting on the statement that
caused the problem. This is true of all of the various exceptions which can
happen. Just change the exception handling in the debugger to stop always
and you should be there. It is best to change it back after you are done as
not doing so can sometimes be confusing, MS sometimes counts on some
exceptions but in this case you should find the problem quickly. Don't
forget that in many cases you call some MS function with junk and it will
cause the exception not you so look up the stack in that case.

--




Jim

If it's reproducable, just put a breakpoint at the beginning of the function
and track all automatic variables that are created. A class with many value
members can also be a problem.

class {
public:
char a[1000000];
}

Well it is (reproductable), but the final function called does not allocate
major variables. In fact, I don't see any of the functions on the call stack
with any variables of significance. Which is why I think that you are
right - there is a class somewhere that contains some large member. But how
can I track this sort of thing down?