Board index » cppbuilder » Where was my program interrupted

Where was my program interrupted


2004-07-05 10:17:34 PM
cppbuilder51
When my program crashes, it often shows a subroutine, for example in dstring.h:
char& __fastcall operator [](const int idx)
{
ThrowIfOutOfRange(idx); // Should Range-checking be optional to avoid overhead ??
Unique(); // Ensure we're not ref-counted
return Data[idx-1];
}
How do I find the error in my program?
 
 

Re:Where was my program interrupted

Feico wrote:
Quote
How do I find the error in my program?
Run it under the IDE then look at the call stack to see where it came
from to get to that point. You can then also use the local variables
window to examine the state of variables at the various points in the
call stack.
You then compare those variables with what you as the programmer would
expect to be in them.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Where was my program interrupted

On 5 Jul 2004 07:24:56 -0700, "Andrue Cope [TeamB]" < XXXX@XXXXX.COM >wrote in
borland.public.cppbuilder.ide:
Quote
>How do I find the error in my program?

Run it under the IDE then look at the call stack to see where it came
from to get to that point.
Well, it shows in which subroutine the error occurred, but not the exact place. I see no other
solution but to set a break point at the beginning of that subroutine, and to press F8 until the
error occurs.
 

{smallsort}

Re:Where was my program interrupted

Feico wrote:
Quote
Well, it shows in which subroutine the error occurred, but not the
exact place.
Okay it wasn't clear from your posting what you actually meant. If you
mean that it shows the error on a function /call/ then I understand the
problem. We get this a lot as well and it is a PITA. Oddly on the
occasions I've mentioned it here before few other people (no one to my
recollection) has ever reported seeing this.
I have no workaround and can only hope that it isn't a function that
gets called a lot or else you can determine the entry conditions that
led up to the AV. Please note that when the de{*word*81} is stopped in this
condition you should be wary of beleiving the values reported in
variables for the current point of execution.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html