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