Tim, Darrell, All,
After much (wasted) effort, I have come to the definite conclusion that the crash seen in kwrite/kate/quanta/konqueror(filemanagement katepart) is 100% due to gcc 4.7.
I just finished a rebuild of current code on gcc 4.6 and kwrite works perfectly/wraps without problem, etc... See:
http://www.3111skyline.com/dl/dt/trinity/ss/kwrite-gcc46-allgood.jpg
Repeating, just a Darrell confirms, building from current GIT on gcc 4.6 is fine, building on gcc 4.7 causes the crash with no FTBFS.
I have no clue what to do next. It is probably premature for a bug against gcc 'wrong code' until somebody can confirm that katerenderer.cpp doesn't violate coding standards.
Sorry for the long troubleshooting process. I should have just taken Tim's advice and rebuilt from 46 is a first step, but sometimes the long way around just can't be avoided.
What to do next?
On 3 May 2012, David C. Rankin stated:
After much (wasted) effort, I have come to the definite conclusion that the crash seen in kwrite/kate/quanta/konqueror(filemanagement katepart) is 100% due to gcc 4.7.
I just finished a rebuild of current code on gcc 4.6 and kwrite works perfectly/wraps without problem, etc... See:
This is evidence, but not proof. It could perfectly well be that GCC is optimizing more heavily than before and that the optimizer is buggy, but it may also be that GCC is optimizing more heavily than before and is breaking code that is invoking undefined behaviour that nobody noticed before now because it didn't break anything. C and C++ are tricksy that way. :)
I have no clue what to do next. It is probably premature for a bug against gcc 'wrong code' until somebody can confirm that katerenderer.cpp doesn't violate coding standards.
Quite so.
What to do next?
Localizing the fault, I'd say. Since GCC 4.6 and 4.7 share the same C++ ABI (unless explicitly instructed otherwise, and if not compiling for C++11), you can binary-search for the faulty file by picking a random half of the files (or directories) and compiling *only them* with GCC 4.7, and compiling the other half with GCC 4.6. If it doesn't crash, flip the halves: otherwise, halve that half and compile one half with 4.6 and one half with 4.7, and iterate until you have only one file left. With only one file left you have a reasonable amount of code to start dissecting by hand for further info.
This is, I know, really really really boring. But it should work. :)
On 05/03/2012 05:55 PM, Nix wrote:
Localizing the fault, I'd say. Since GCC 4.6 and 4.7 share the same C++ ABI (unless explicitly instructed otherwise, and if not compiling for C++11), you can binary-search for the faulty file by picking a random half of the files (or directories) and compiling *only them* with GCC 4.7, and compiling the other half with GCC 4.6. If it doesn't crash, flip the halves: otherwise, halve that half and compile one half with 4.6 and one half with 4.7, and iterate until you have only one file left. With only one file left you have a reasonable amount of code to start dissecting by hand for further info.
This is, I know, really really really boring. But it should work. :)
That makes sense. I have kicked off a gcc47 build with todays GIT tree that will complete later this evening. If I'm still up, I'll start another build with gcc46. Then we will have a gcc46 and gcc47 set of files. I guess we would then want to install the gcc46 files and then incrementally install/test/remove the gcc47 files until we find the file that causes the failure. Once built, it shouldn't be that bad since there are only 3 prime candidates -- tqt3, tdelibs, tdebase.
Boring? I like watching paint dry...
On 4 May 2012, David C. Rankin told this:
That makes sense. I have kicked off a gcc47 build with todays GIT tree that will complete later this evening. If I'm still up, I'll start another build with gcc46. Then we will have a gcc46 and gcc47 set of files. I guess we would then want to install the gcc46 files and then incrementally install/test/remove the gcc47 files until we find the file that causes the failure.
You'll want to link, install, test, and remove. But, yes, doing it from a pre-existing pair of piles of object files is faster than what I was thinking of. :)
Once built, itshouldn't be that bad since there are only 3 prime candidates -- tqt3, tdelibs, tdebase.
Though each of those has *lots* of files. Still, the log2 of that number isn't so bad.
Boring? I like watching paint dry...
'Blackchapel, for most of its history, was a quiet little village. Indeed, the noted traveler Ustav of Leramont, one of the first human beings to visit, noted that a day spent in the village was, as he put it, "as exciting as watching two pieces of granite involved in a staring contest," and added, "I eagerly looked forward to my night’s rest as a means of relieving my ennui."' -- Steven Brust (translating Paarfi of Roundwood), _The Paths of the Dead_
-
David C. Rankin -
Nix