------- Comment #16 from nigelenki at comcast dot net 2006-07-11 07:08 -------
(In reply to comment #15)
> (In reply to comment #14)
>
...
> > Yes but now he has a limited number of code paths to go wrong on.
>
> That is not true. he just knows the last function and nothing more, this is
> where a debugger comes in handy to get the full backtrace. You seem to think
> getting where the crash is, is a magic bullet at fixing an issue which it is
> not. It sometimes (less than 5%) can be a magic bullet but then using a debug
> is part of the development cycle.
>
Actually, here's what I think:
int main() {
__foo();
}
void __foo() {
__bar();
__baz();
}
void __bar() {
__qux();
}
void __baz() {
return;
}
void __qux() {
int a[5];
strcpy(a, "hello!!!!!!");
}
Of main(), __foo(), __bar(), __baz(), and __qux(), the problem can only be in
main(), __foo(), __bar(), or __qux(). The problem can NOT be in __baz().
Yes, maybe if __baz() was called before __bar() and alters data __qux() uses
(i.e. data to be passed, or global data), then we include __baz() in the
equation. My point is in a large program there will be functions that
effectively don't matter. There is a large chance that the bug occurred
recently relative to a crash.
> > Um, there are only so many code paths that lead you to f(). There's a LOT
> > of
> > code you can cut out of your program now...
>
> What from 100 million down to 90 million, yes you cut the problem down by 1%
> but there still can be a huge amount to go.
>
Each time you use a piece of data that is in an inconsistent state with what
the program expects, you have a chance of causing damage. Each time you cause
damage, you have a chance of creating a fatal condition.
Probaibilisticly, the more you use a piece of damaged data, the more likely the
program is to experience a fatal bug. To make a long story short, it's highly
likely that the bug was recently caused; and highly unlikely that you can go
all the way back to a bug in main() through 90 million lines of called code and
find the problem.
Of course that's just mathematic theory.
>
> > And you pick up the "Emergency Phone," and the operator says, "open the
> > panel,
> > there's a number displayed, what does it say?" and you blindly say "37" and
> > they go to an exact panel in an exact room and work backwards from there
> > instead of combing the entire elevator system.
>
> but that is how you reproduce the bug
Actually that's more like an error code ("Experienced error 107" "Error 404
Object Not Found" etc). Which is debugging information.
>
> No you get almost no more information about the problem if you get a bug
> report
> with just where it crashes, even GCC gets those because people don't read
> instructions.
hey when I've reported gcc bugs, gcc was complaining that it failed to
spill/fill a register or something and gave me the file it was trying to use.
I passed it a switch to keep the preprocessed output, and attached that to the
bug, and you guys figured out what the problem was.
I would have got as far as saying "Internal compiler error" if it died with
"ICE failure to spill/fill. Please report." As it stands it at least was able
to tell me what file it was trying to compile. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
