Debugging stack overflows..

  • Thread starter Thread starter Søren Johansen
  • Start date Start date
S

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
 
Søren Johansen said:
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.
Click to expand...

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];
}
 
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];
}
Click to expand...

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?
 
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

Søren Johansen said:
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];
}
Click to expand...

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?
Click to expand...
 
Back
Top