3 May
2012
3 May
'12
6:13 p.m.
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?
--
David C. Rankin, J.D.,P.E.
3 May
3 May
10:55 p.m.
New subject: [trinity-devel] No WILD GEESE gcc 4.7 => kwrite/kate crash, gcc 4.6 current code == All Good!
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. :)
--
NULL && (void)
11:06 p.m.
New subject: [trinity-devel] No WILD GEESE gcc 4.7 => kwrite/kate crash, gcc 4.6 current code == All Good!
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...
--
David C. Rankin, J.D.,P.E.
4 May
4 May
12:25 p.m.
New subject: [trinity-devel] No WILD GEESE gcc 4.7 => kwrite/kate crash, gcc 4.6 current code == All Good!
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, it
shouldn'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_
4616
days inactive
4617
days old
3 comments
2 participants
participants (2)
-
David C. Rankin -
Nix