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