Profiling or Debugging Help

[Mike Copeland]

Using VS6.0...
I have developed a 32bit Console application that has started to
abort with Stack faults at predictable and repeatable intervals. From
what I read, there's a presumed level of recursion being exceeded
(actually, I doubt that...) or subroutine nesting that is too high.
Looking at the code doesn't seem to bear out either...
I'm seeking some way to "profile" this application, so that I can see
where the problem is occurring. I have the faulting address, but I
don't know how to use that information.
The problem occurs when I run this program in its intended
environment: Windows 98 on laptops. I cannot get this error to occur in
the VS6.0 IDE (where it might be easier to track down the problem), and
I'm wondering what tools, information, or techniques might help me
discover and fix the problem.
Perhaps there's a compiler setting that might increase the Stack
limit, but beyond a temporary fix that's not a permanent solution I want
to use.
Any thoughts? TIA

[Victor Bazarov]

Post by Mike Copeland
Using VS6.0...
I have developed a 32bit Console application that has started to
abort with Stack faults at predictable and repeatable intervals. From
what I read, there's a presumed level of recursion being exceeded
(actually, I doubt that...) or subroutine nesting that is too high.
Looking at the code doesn't seem to bear out either...

You're probably stomping all over your stack by writing beyond the
boundary of a local array.

Post by Mike Copeland
I'm seeking some way to "profile" this application, so that I can see
where the problem is occurring. I have the faulting address, but I
don't know how to use that information.
The problem occurs when I run this program in its intended
environment: Windows 98 on laptops. I cannot get this error to occur in
the VS6.0 IDE (where it might be easier to track down the problem), and
I'm wondering what tools, information, or techniques might help me
discover and fix the problem.

Very few.

Post by Mike Copeland
Perhaps there's a compiler setting that might increase the Stack
limit, but beyond a temporary fix that's not a permanent solution I want
to use.
Any thoughts? TIA

See above. Memory overruns are difficult to debug because their effects
are not known until some time after they've occurred.

Good luck!

V

[Ulrich Eckhardt]

Post by Mike Copeland
Using VS6.0...

This product is now more than ten years old and unsupported. It might be the
right choice considering that you target similarly obsolete win98 though.
Just wanted to mention that.

Post by Mike Copeland
I have developed a 32bit Console application that has started to
abort with Stack faults at predictable and repeatable intervals. From
what I read, there's a presumed level of recursion being exceeded
(actually, I doubt that...) or subroutine nesting that is too high.

What exactly do you get as error?

Post by Mike Copeland
Looking at the code doesn't seem to bear out either...
I'm seeking some way to "profile" this application, so that I can see
where the problem is occurring. I have the faulting address, but I
don't know how to use that information.
The problem occurs when I run this program in its intended
environment: Windows 98 on laptops. I cannot get this error to occur in
the VS6.0 IDE (where it might be easier to track down the problem), and
I'm wondering what tools, information, or techniques might help me
discover and fix the problem.

On what OS are you running VC6? If not on win98, you might try to do that
for a test. You can also activate debug symbols for release builds
(debugging gets a bit whacky due to the optimizer, but is feasible). You
could also checkpoint the stack consumption by storing a local var's
address in main() and then comparing with other locals' addresses lateron
to see how far they are apart. Lastly, I believe that the win32 API allows
detecting and handling stack overflows, I seem to remember that Boost.Regex
uses this feature to properly handle bloated regular expressions.

Post by Mike Copeland
Perhaps there's a compiler setting that might increase the Stack
limit, but beyond a temporary fix that's not a permanent solution I want
to use.

That's in the linker settings. Further, you can specify a stack size when
creating threads. You could try to reduce the stack size and see if the
problem then occurs on your development machine or increase it and see if
it vanishes on the target machine.

Uli

[Mike Copeland]

Post by Ulrich Eckhardt

Post by Mike Copeland
Using VS6.0...

This product is now more than ten years old and unsupported. It might be the
right choice considering that you target similarly obsolete win98 though.
Just wanted to mention that.

No other option - I'm a poor, old independent developer who can't
afford to purchase a newer product, and I don't particularly want to
migrate a a new, free product (too many legacy applications already
being supported). I know it's an old product, but it serves me well
enough for what I do... 8<}}

Post by Ulrich Eckhardt

Post by Mike Copeland
I have developed a 32bit Console application that has started to
abort with Stack faults at predictable and repeatable intervals. From
what I read, there's a presumed level of recursion being exceeded
(actually, I doubt that...) or subroutine nesting that is too high.

What exactly do you get as error?

Stack Fault popup window, from which I can get to the faulting
address.

Post by Ulrich Eckhardt

Post by Mike Copeland
Looking at the code doesn't seem to bear out either...
I'm seeking some way to "profile" this application, so that I can see
where the problem is occurring. I have the faulting address, but I
don't know how to use that information.
The problem occurs when I run this program in its intended
environment: Windows 98 on laptops. I cannot get this error to occur in
the VS6.0 IDE (where it might be easier to track down the problem), and
I'm wondering what tools, information, or techniques might help me
discover and fix the problem.

On what OS are you running VC6? If not on win98, you might try to do that
for a test.

Windows XP SP3.

Post by Ulrich Eckhardt
You can also activate debug symbols for release builds
(debugging gets a bit whacky due to the optimizer, but is feasible). You
could also checkpoint the stack consumption by storing a local var's
address in main() and then comparing with other locals' addresses lateron
to see how far they are apart. Lastly, I believe that the win32 API allows
detecting and handling stack overflows, I seem to remember that Boost.Regex
uses this feature to properly handle bloated regular expressions.

I'll look into that - thanks.

Post by Ulrich Eckhardt

Post by Mike Copeland
Perhaps there's a compiler setting that might increase the Stack
limit, but beyond a temporary fix that's not a permanent solution I want
to use.

That's in the linker settings. Further, you can specify a stack size when
creating threads. You could try to reduce the stack size and see if the
problem then occurs on your development machine or increase it and see if
it vanishes on the target machine.

Also things to try... 8<}}

[mzdude]

   Using VS6.0...
   I have developed a 32bit Console application that has started to
abort with Stack faults at predictable and repeatable intervals.  From
what I read, there's a presumed level of recursion being exceeded
(actually, I doubt that...) or subroutine nesting that is too high.  
Looking at the code doesn't seem to bear out either...

<snip>

   Any thoughts?  TIA

If you are stomping over the stack due to an errant memory write,
sometimes a static analysis tool (like PC-Lint) can find the error. Or
possibly point you in the right direction.

If you have never used a static analysis tool, be warned, it does
take sometime to get up to speed and tune it for your development
tastes.