| Summary: | Nautilus 2.6.1 crash | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Evan Langlois <evan> |
| Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | VERIFIED INVALID | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Evan Langlois
2004-05-16 22:17:50 UTC
first rule of bugreporting : tune down those freaking CFLAGS. The cflags were originally -O3 -fomit-frame-pointer -march=pentium3 -pipe I highly doubt this is a CFLAG issue. I'd be looking at the code. If it is a CFLAG issue, then the compiler has a bug - either way there is a bug. I will recompile nautilus with just -O2 and let you know. Seems to work with -O2. So is this a compiler bug? Should certain CFLAGS be removed by the nautilus ebuild? no, your CFLAGS are your responsibility beyond reasonable defaults. You should just be aware that long lines of pretty crazy CFLAGS will get you in trouble at one point or the other. Or in cases like this one, it helps show bugs that exist in the code. Changing optimization flags should not break the program - if it does, its a compiler bug or a bug in the program. Even with -O2, I was able to repeat the problem once. Adding tons of optimization flags makes the problem repeatable. well obviously you compiled your whole system like that, so recompiling a few components may still prove instable at times. But i guess you build your system like that to expose bugs others wouldn't regularly encounter. But you seem well versed in these things, so why don't you debug your crash and device us a fix ? Certain optimizations certainly can & will break programs in our not so ideal world. Actually, most of the system was installed from the 2004.1 GRP CD, and then upgraded to current with -O3 -march=pentium3 -fomit-frame-pointer -pipe. I do have ACCEPT_KEYWORDS="~x86" globally, so its pushing the leading edge a bit. This is my typical set of CFLAGS. The extra cruft which was in the post was a recent change that I did for testing a few things (trying to see if I squeeze a bit more performance out of mplayer - didn't think it would help - but I wanted to try it). I wasn't sure if nautilus had been upgraded again after I made that change so I left it. I suppose I should just quit reporting bugs since you seem so quick to deny that there is a problem. Reminds me of some horrible bugs I fixed at work, and even after it was fixed the original author still denied that there was anything wrong. When I have the time to play with nautilus all day long changing the views to make it crash again, I'll let you know. Until then, the next person who has this problem can find this bug number, but I hope they are ready to prove its a bug by recompiling there entire system with CFLAGS="-O" emerge -e world. Because its so obvious that there isn't a bug in the program, nor its compiler, when a program locks up and dies. mplayer resets all CFLAGS afaik, because it tends to bug about with anything but default CFLAGS (another one for your 'everything should work with all optimizations statement'). I'm quick to invalidize bugs we cannot possibly handle because it's plain asking for trouble to go to the edge of optimizations. And then complain if something crashes and cannot be reproduced consistently (not even by you). I could've predicated instability beforehand. I don't say there's something wrong somewhere, but it is _FAR_ from realistic to expect us to debug your optimizations related problem for you. It's pretty much outrageous to ask that from us. But it's quite normal for bugreporters to feel offended and mistreated when their obviously self-inflicted problems tend to be dismissed, we've grown accustomed to it over the time. I guess we'll have to live with the disrespect we get for free. |
