[Bug other/28328] Stack smash protection non-verbose

["nigelenki at comcast dot net" <gcc-bugzilla at gcc dot gnu dot org>]

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