[Bug c/28328] New: Stack smash protection non-verbose

[Bug c/28328] New: Stack smash protection non-verbose

[nigelenki at comcast dot net]

In the original ProPolice that the gcc 4.1 stack smash protection was derived
from, a stack smash would illicit a message similar to:


*** Stack smashing detected in function vuln() in source file net.c!!! Aborted

Examining the current source, the following code exists:

void
__stack_chk_fail (void)
{
  const char *msg = "*** stack smashing detected ***: ";
  fail (msg, strlen (msg), "stack smashing detected: terminated");
}

This winds out with:

*** stack smashing detected ***: ./usr/lib/foxsrt/test/ssp_smash terminated

Unfortunately it seems this now can't be (cleanly) fixed without breaking
existing stack smash protected code.  The only way to allow old behavior is to
add ANOTHER external function to libssp.  One possible would be:

void
__stack_chk_fail2 (char *fctn, char *srcfile, void *damage)
{
  const char *msg = "*** stack smashing detected ***:";
  /*Allocate: "%s %s:%s (damage: 0x%p) ",msg,srcfile,fctn,damage*/
  int msg2len = strlen (msg) + strlen (fctn)
                + strlen (srcfile) + sizeof(void*)*2 + 17;

  char *msg2 = alloca (msg2len);

  snprintf (msg2, msg2len, "%s %s:%s (damage: 0x%p) ",
        msg, srcfile, fctn, damage);
  /* Not necessary, assuming %p doesn't spit out extra characters...*/
  msg2[msg2len - 1] = '\0';

  fail (msg2, strlen (msg2), "stack smashing detected: terminated");
}

The emitted code would then have to call the following in case of a detected
stack smash:

__stack_chk_fail2(__FUNC__, __FILE__, __guard);

Where __FUNC__ is the function name, __FILE__ is the source file, and __guard
is the canary value in the function (which is now damaged).

The nice thing about doing something like this is that the programmer does not
have to pull out a debugger and try to reproduce stack smashing scenarios and
do a stack trace to figure out where the bug is.  This is especially helpful
when an end user produces a bug report, because the bug report can say right
there, "Stack smash in bad_code.c:vuln_function()" and the programmer can go
right there and look through everything that the buffer is passed to and
everything he does with it to see what he messed up.

The overhead of this is an extra reference to __FILE__ and __FUNC__, which may
be generated inline or point to existing copies of those strings in the object.
 The cost at runtime is only seen when a stack smash occurs.  Total, the
program should get a few bytes bigger (if alignment doesn't fuzz that out) and
shouldn't run any slower, so nobody should care.


-- 
           Summary: Stack smash protection non-verbose
           Product: gcc
           Version: 4.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: nigelenki at comcast dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328

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

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-07-10 21:26 -------
Why not use a debuger to debug your program when stack smasher happens?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |other


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328

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

[nigelenki at comcast dot net]

------- Comment #2 from nigelenki at comcast dot net  2006-07-11 02:43 -------
The program may be on an end user system that A) has insufficient debugging
data compiled in (though I'd imagine you know what function it's in anyway); or
B) has an end user that can't/won't debug (typical).  It may also be difficult
to reproduce the crash the user experiences when a stack smash occurs (hence
why I am considering filing a bug about ALWAYS reporting stack smashing to
syslog() to go with this*).

Imagine an Ubuntu, Fedora Core, Mandriva, XandrOS, or MEPHIS Linux user
encountering a mysterious crash that happens to be a stack smash.  These
distributions are largely aimed at typical users that will A) ignore it; or B)
run to IRC and go "help help wut happen :(" and then bail out before reaching
bugzilla.  At least in the case of (B) someone can say "Type dmesg" or "hit
system->logs and click security and tell me what it says"* and instantly have
useful data.

Another thought I had is that the stack trace may be destroyed; but this is not
an issue, since the current function calls __stack_chk_fail() and thus passes
us the current address, allowing us to find the function owning the overflowed
buffer.  This of course is only useful if the program happens to smash the
stack while running in a debugger.

*See bug #28334


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328

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

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-07-11 03:02 -------
If an end user gets a stack smash failure, they should report the bug to the
developer and have the developer fix it.
This is what is normally done for anyother bug, why should it be different than
a stack smashing one?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328

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

[nigelenki at comcast dot net]

------- Comment #4 from nigelenki at comcast dot net  2006-07-11 03:09 -------
(In reply to comment #3)
> If an end user gets a stack smash failure, they should report the bug to the
> developer and have the developer fix it.
> This is what is normally done for anyother bug, why should it be different than
> a stack smashing one?
> 

Because, like any normal report, it will go something like this:

END USER:

  xmms crashed

DEVELOPER:

  I need more info.

END USER:

  it crashed what do u mean

DEVELOPER:

  Why did it crash?

END USER:

  i unno it just did it was playin mp3s n it died

DEVELOPER:

  Did a specific MP3 cause it to crash?

END USER:

  maybe i cant make it do it agan tho i dunno y

DEVELOPER:

  Huh.  Meh.  I'll figure it out some time next year.



I would ultimately rather the report go like this:

END USER:

  xmms crashed

DEVELOPER:

  OK, can you see why?  First you should check 'dmesg | grep stack smash | grep
xmms'

END USER:

  ** stack smashing detected ***: mpg123_decode.c:decode_spline() (damage:
0xdeadbeef) Terminated

DEVELOPER:

  Thank you, I see the problem, there's a patch attached.  Your distribution
should have a new version some time in a couple days.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328

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

[solar at gentoo dot org]

------- Comment #5 from solar at gentoo dot org  2006-07-11 04:25 -------
John is mostly right in reporting this.

Gentoo uses SSP more than anyone else out there for longer than most 
anybody (obsd excluded) and I can't stress how vital it is to have the
function hint that Etoh's original __stack_smash_handler() offered from
a distro point of view.

When the initial porting of etohs code was done for 4.x this feature 
should of been ported also but sadly was not.

I would ignore the part in his comments about syslog() as running the 
handler past that would mean that all vio/*intf functionality would
have to have ssp disabled on it in *libc which pretty much means all of
the libc.

And dmesg() is moot cuz ssp userland handlers can't really reach that 
level of the kernel nor should they try.

This bug should get itself assigned.


-- 

solar at gentoo dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |solar at gentoo dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328

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

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2006-07-11 04:27 -------
(In reply to comment #4)
>   Thank you, I see the problem, there's a patch attached.  Your distribution
> should have a new version some time in a couple days.

Here is how normal GCC bugs go:
User (which is a developer, not neccessary of GCC): I ran some code through GCC
and GCC produced an internal compiler error.

Developer of GCC (if they did not follow the directions on the web page): Can
you attach the preprocessed source as mentioned on http://gcc.gnu.org/bugs.html

(if they did attach it, it is usually easy to figure out what is going on).

Really the developer should set up a correct way of reporting a bug, what they
require to report the bug.  Like your example, xmms instructions should be
like:
attach the sound file you were trying to play.
Everything else should fall out from there.  Now if developer's don't care
about their user that much, the user will move away from that program.  This is
called common sense about supply and demand.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328

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

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-07-11 04:31 -------
(In reply to comment #5)
> This bug should get itself assigned.

You know like many other open source projects, if you really want a feature you
should implement it.  As I mentioned in the other bug, knowing where something
crashed is only part of the story on debugging, you also need to know why,
which can be much harder to see as the problem comes from 1000 lines before. 
So getting this info is only useful for obvious bugs which someone could spot
by going through the code line by line.

Also the user should not know your internals of your program, it just confuses
them and in fact it might cause some of IP to be exposed and you don't want
that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328

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

[nigelenki at comcast dot net]

------- Comment #8 from nigelenki at comcast dot net  2006-07-11 04:56 -------
(In reply to comment #6)
> (In reply to comment #4)
> >   Thank you, I see the problem, there's a patch attached.  Your distribution
> > should have a new version some time in a couple days.
> 
> Here is how normal GCC bugs go:

...

> attach the sound file you were trying to play.
...

But but!  I have 18,397 files in XMMS!  It was on another virtual desktop when
it crashed!  It was in shuffle mode!  I don't KNOW what file it was trying to
play and I can't get it to reproduce it!

Compilers are easy.  They die and say "holy crap I was trying to process this
and my tree did this and I failed to spill a register help!" and you go to the
bugzilla and go "It told me to give you this file it spit out" and go home.
(In reply to comment #5)

> John is mostly right in reporting this.
> 

...

> I would ignore the part in his comments about syslog() as running the 
> handler past that would mean that all vio/*intf functionality would
> have to have ssp disabled on it in *libc which pretty much means all of
> the libc.

Yeah, ignore that, it can be dealt with distro-side and I'll find another way
that's friendlier.  open and a named pipe, or a UNIX socket, or something.  The
handler's exact function can be altered without an API change.

(In reply to comment #7)
> (In reply to comment #5)
> > This bug should get itself assigned.
> 
> You know like many other open source projects, if you really want a feature you
> should implement it.

I'll try with 4.1.1 but I warn you I have no idea how gcc works internally. 
Gimme a little help if I get stuck?  :)

I'll poke the gcc ML if I get anywhere.  I guess I'll start by unit testing my
stack check fail function.

>  As I mentioned in the other bug, knowing where something
> crashed is only part of the story on debugging, you also need to know why,
> which can be much harder to see as the problem comes from 1000 lines before. 

Actually it won't come from 1000 lines before.  It'll go like this:

int vuln(char *s, int len) {
  char a[10];
  char b[20];

  a[0] = 0;
  strcpy(a, "str: ");
  strcat(a, s);
  return strlen(a);
}

Result:
*** stack smashing detected ***: vuln.c:vuln() (damage: 0xdeadbeef) /bin/vuln
Terminated

We know that we trashed a[] or b[].  Let's imagine there's 3000 other
functions, and figure out where to look... oh, in vuln.c in vuln().

> So getting this info is only useful for obvious bugs which someone could spot
> by going through the code line by line.

Of course you could write a test case for your code, if you know where your
code is breaking.

> 
> Also the user should not know your internals of your program, it just confuses
> them and in fact it might cause some of IP to be exposed and you don't want
> that.
> 

Confusing the user is a shoddy argument.  What's the alternative?  "Attempt to
reproduce it, even though you can't after 5 hours"?  "Run it through gdb,
because I can't reproduce it on my end"?  Trust me if you say to the user, "It
should spit out something like 'IP: 0x7b, SP: 0x99, stack dump: 00 77 de ad be
ef ca fe ba be', give me that," he'll go "uh... okay... don't know how you can
make any sense of any of that junk but..."

IP exposure is a shoddy argument, a static function name is not important and
an external function name is readable via readelf -s.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328

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

[solar at gentoo dot org]

------- Comment #9 from solar at gentoo dot org  2006-07-11 04:57 -------
(In reply to comment #7)
> (In reply to comment #5)
> > This bug should get itself assigned.
> 
> You know like many other open source projects, if you really want a feature you
> should implement it. 

I would not have a problem doing that when I have some free time and am 
ready to move to gcc-4.x.

> As I mentioned in the other bug, knowing where something
> crashed is only part of the story on debugging, you also need to know why,
> which can be much harder to see as the problem comes from 1000 lines before. 
> So getting this info is only useful for obvious bugs which someone could spot
> by going through the code line by line.
> 
> Also the user should not know your internals of your program, it just confuses
> them and in fact it might cause some of IP to be exposed and you don't want
> that.

Sorry but as somebody that has been an active supporter of ssp over the 
years and somebody thats fixed dozens of bugs spotted by ssp your
statement is not really valid about exposing a function name to end
users. You might be surprised in fact at how many end users are also
problem solvers. The printing a function name is not really an info
leak nor is it exposing IP anymore than say looking .dynstr itself. I
don't mean in anyway to insult you in saying so. I'm just saying I know
what I'm talking about as somebody who has delt with many bugs with 
respect to this very thing.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328

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

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2006-07-11 05:25 -------
(In reply to comment #8)

> Actually it won't come from 1000 lines before.  It'll go like this:
> 
> int vuln(char *s, int len) {
>   char a[10];
>   char b[20];
> 
>   a[0] = 0;
>   strcpy(a, "str: ");
>   strcat(a, s);
>   return strlen(a);
> }

That is just a simple (obvious) example, you seem to not understand how real
code looks like.  You might instead have:

int f(int a, int b)
{
  int f[10];
.....
  f[a] = 1;
....
  return f[b];
}

Where you know that a should be between 0 and 9 but comming into the function
it is not, so the value of a is wrong and you have to track down why that is
which can be a million lines in execution before calling of f.  This is a stack
smashing bug also, yes a less common one than the obvious ones which you showed
but it is still going to happen.  The obvious ones are easy to find in an audit
of the code, unlike this one.  You can add asserts to the function but that
will produce as much useful info as the info you want from the stack smasher. 
It is only useful for starting to debug the program, even then you get the
information just as quick from the debugger.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328

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

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2006-07-11 05:32 -------
(In reply to comment #9)
> Sorry but as somebody that has been an active supporter of ssp over the 
> years and somebody thats fixed dozens of bugs spotted by ssp your
> statement is not really valid about exposing a function name to end
> users. 

I am not saying ssp is bad, I am saying it is only a small tool in
debuging/development and should be kept that way.  If there are trust problems,
then ssp is used and the end user is not trusting the developer of the program
anyways.  Oh you don't know lawyers (or non open source companies) that well
when it comes to IP :).

> You might be surprised in fact at how many end users are also
> problem solvers. 

You are talking about gentoo end users and end users who actually semi care
about being semi developers which have to be problem solvers.  You forget about
real end users like say a game player.  He does not care why your program
crashes, he just wants a fix or he might just ask for a refund since your
program does not work.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328

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

[nigelenki at comcast dot net]

------- Comment #12 from nigelenki at comcast dot net  2006-07-11 05:49 -------
(In reply to comment #10)
> (In reply to comment #8)
> 

> That is just a simple (obvious) example, you seem to not understand how real
> code looks like.  You might instead have:
> 
> int f(int a, int b)
> {
>   int f[10];
> .....
>   f[a] = 1;
> ....
>   return f[b];
> }
> 
> Where you know that a should be between 0 and 9 but comming into the function
> it is not, so the value of a is wrong and you have to track down why that is
> which can be a million lines in execution before calling of f.  This is a stack
> smashing bug also, yes a less common one than the obvious ones which you showed
> but it is still going to happen.  The obvious ones are easy to find in an audit
> of the code, unlike this one.  You can add asserts to the function but that
> will produce as much useful info as the info you want from the stack smasher. 
> It is only useful for starting to debug the program, even then you get the
> information just as quick from the debugger.
> 

You make the assumption that I somehow know the bug is in f().  What if I have
a 64 million line program with several hundred thousand functions like this,
and the bug is obscure and hard to reproduce?  Where do I start?  How do I know
the bug is in f()?

(In reply to comment #11)
> (In reply to comment #9)

...

> 
> I am not saying ssp is bad, I am saying it is only a small tool in
> debuging/development and should be kept that way.

Don't worry, it will be.  I am only interested in getting a facility to obtain
information that says to "start somewhere around here."

>  If there are trust problems,
> then ssp is used and the end user is not trusting the developer of the program
> anyways.

SSP is a safety net.  If you can't trust the developer of the program, then you
assume the program is malicious, and don't run it because it's backdoored.  SSP
is not a tool to stop untrusted developers, it's a tool to catch minor
mistakes.

.....

> You forget about
> real end users like say a game player.  He does not care why your program
> crashes, he just wants a fix or he might just ask for a refund since your
> program does not work.
> 

"I am experiencing a crash on level 10, sometimes when I enter this room"

  "OK we'll look into it"  *months go by*

How about:

"I am experiencing a crash on level 10, sometimes when I enter this room"

  "OK, look in ~/level_10_dump.dbg, send me that file" (game supplies an
overriden __stack_chk_fail() that also spits out a debug file) *patch released
4 days later*

I've heard enough stories about being on the phone with Apple for a total of 50
hours or whatnot, it's been fun but I'd rather just e-mail a file or copy-paste
a line of text and be done.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328

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

[pinskia at gcc dot gnu dot org]

------- Comment #13 from pinskia at gcc dot gnu dot org  2006-07-11 06:00 -------
(In reply to comment #12)
> (In reply to comment #10)
> > (In reply to comment #8)
> > 
> 
> > That is just a simple (obvious) example, you seem to not understand how real
> > code looks like.  You might instead have:
> > 
> > int f(int a, int b)
> > {
> >   int f[10];
> > .....
> >   f[a] = 1;
> > ....
> >   return f[b];
> > }
> > 
> > Where you know that a should be between 0 and 9 but comming into the function
> > it is not, so the value of a is wrong and you have to track down why that is
> > which can be a million lines in execution before calling of f.  This is a stack
> > smashing bug also, yes a less common one than the obvious ones which you showed
> > but it is still going to happen.  The obvious ones are easy to find in an audit
> > of the code, unlike this one.  You can add asserts to the function but that
> > will produce as much useful info as the info you want from the stack smasher. 
> > It is only useful for starting to debug the program, even then you get the
> > information just as quick from the debugger.
> > 
> 
> You make the assumption that I somehow know the bug is in f().  What if I have
> a 64 million line program with several hundred thousand functions like this,
> and the bug is obscure and hard to reproduce?  Where do I start?  How do I know
> the bug is in f()?

Right, you just admitted this is information is only useful when the problem is
obvious which 95% of the time it is not.  So you get only a very small part of
the story from the information which you are requesting to be outputed, in fact
the developer still has to debug the program and to see why it is wrong.  It
might be a misleading to the developer to get where the problem shows up rather
than where the problem really is caused from.  Different developers have
different style of debugging so why push one style debuging on them?

Again the end user does not care why it crashes, they only care if it is fixed.
Think of the issue this way, when you ride on an elevator, and it stops
working, you don't care why, you just care it gets fixed.  This is how software
should be dealt with but really developer's are not held up to that standard
for some reason except in the case where it is life and death can occur (well
technically it can occur any time with real programs because they could cause
someone to have a cesure).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328

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

[nigelenki at comcast dot net]

------- Comment #14 from nigelenki at comcast dot net  2006-07-11 06:25 -------
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #10)
> > > (In reply to comment #8)
> > > 
> >

...

> > 
> > You make the assumption that I somehow know the bug is in f().  What if I have
> > a 64 million line program with several hundred thousand functions like this,
> > and the bug is obscure and hard to reproduce?  Where do I start?  How do I know
> > the bug is in f()?
> 
> Right, you just admitted this is information is only useful when the problem is
> obvious which 95% of the time it is not.

Uh, ACTUALLY I just pointed out the scenario where the developer has no idea
what the end user did; the end user knows he has a problem but that's it; and
the developer would have to check the ENTIRE code base blindly if the end user
couldn't just tell him "Oh it said it blew up a buffer in f(), whatever that
means."

In other words I just showed that I saved the developer thousands of man-hours
of work.


> in fact
> the developer still has to debug the program and to see why it is wrong.

Yes but now he has a limited number of code paths to go wrong on.

>  It
> might be a misleading to the developer to get where the problem shows up rather
> than where the problem really is caused from.

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

>  Different developers have
> different style of debugging so why push one style debuging on them?

We're just volunteering more information, not forcing them to use it.  Kind of
like keeping soda in the fridge.  Maybe you don't drink soda, but it's better
than keeping nothing so everyone has to drive out to the store when they're
thirsty.

> 
> Again the end user does not care why it crashes, they only care if it is fixed.

Right.  It crashed, here's the file you asked me to e-mail, fix the damn thing.

> Think of the issue this way, when you ride on an elevator, and it stops
> working, you don't care why, you just care it gets fixed.

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.

>  This is how software
> should be dealt with but really developer's are not held up to that standard
> for some reason except in the case where it is life and death can occur (well
> technically it can occur any time with real programs because they could cause
> someone to have a cesure).
> 

So, you are saying that software should be dealt with by an end user saying, "I
don't know why it broke, fix it;" rather than saying, "I don't know why it
broke, it asked me to e-mail you this file.  Here, now fix it"?  (literal, this
is the ENTIRE conversation, you get NO MORE information from the end user on
the problem).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328

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

[pinskia at gcc dot gnu dot org]

------- Comment #15 from pinskia at gcc dot gnu dot org  2006-07-11 06:45 -------
(In reply to comment #14)

> > > 
> > > You make the assumption that I somehow know the bug is in f().  What if I have
> > > a 64 million line program with several hundred thousand functions like this,
> > > and the bug is obscure and hard to reproduce?  Where do I start?  How do I know
> > > the bug is in f()?
> > 
> > Right, you just admitted this is information is only useful when the problem is
> > obvious which 95% of the time it is not.
> 
> Uh, ACTUALLY I just pointed out the scenario where the developer has no idea
> what the end user did; the end user knows he has a problem but that's it; and
> the developer would have to check the ENTIRE code base blindly if the end user
> couldn't just tell him "Oh it said it blew up a buffer in f(), whatever that
> means."
> 
> In other words I just showed that I saved the developer thousands of man-hours
> of work.

Not really, since they still have to figure out if it was already fixed in a
different version or not.  If the bug report was good on how to reproduce it,
like I have $10,000 when I enter level 10 and it crashes.  The developer knows
how to set the paramters to get to right before that point and then try to
reproduce it.  Random failures are the hardest to reproduce and sometimes it is
actually not the developer's fault like the hardware is failing (like the
computer is overheating which yes I have been able to happen to me already but
since I know the symtom of hardware overheating I know the fix too).

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



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




> 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


> So, you are saying that software should be dealt with by an end user saying, "I don't know why it broke, fix it;" rather than saying, "I don't know why it
> broke, it asked me to e-mail you this file.  Here, now fix it"?  (literal, this  is the ENTIRE conversation, you get NO MORE information from the
> end user on the problem).

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.  That information is only useful once you can reproduce the issue
and by then you should have fired up the debugger to be able to debug it.

Also this is why software has instructions on how to file a bug report.  If the
software program does not, then it is really not something you should be able
to trust to run and you should be not running it, unless you are willing to be
able to suffer through the bugs.  Yes I suffer through the bugs for an IRC
client I run because I am too lazy to report the bug and it only is
reproduciable everyonce in a while and I don't care about that much.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328

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

[nigelenki at comcast dot net]

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