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