2 May
2012
2 May
'12
10:56 p.m.
Tim, Darrell, All:
I rebuilt TDE from 4/1 sources with full debug in attempt to further look into
the kwrite crash that Darrell and I have experienced with TDE built on gcc 4.7.
With this build, if it is a source/bad patch/tde issue, then with my 3/29 build
giving no crash and my 4/1 build crashing, that would point to some problem in
between those two dates. However, I am coming around to the thought that -- this
isn't a TDE problem and is more likely a problem introduced by the gcc 4.7
interpretation of the TDE code. I will still have to build the 3/29 sources with
gcc 4.7 to confirm that to be the case. I have 3/29 binaries that work fine
(which I'm fairly sure were built on gcc 4.7, but I can't remember). If I
rebuild with gcc47 on the 3/29 sources and get the same failure -- that, in my
mind, conclusively points to the problem being gcc47.
If that is the case -- how in the heck do you debug something like that? I
don't even know where to begin. (well, I do, but that's by asking). So with full
debug packages built, on the 4/1 sources, I get the following backtrace. If this
doesn't point to anything specific, then all we can do is wait on the 3/29 build
to finish. Let me know if you see anything in this backtrace:
0x00007f1723b65947 in KateLineRange (this=0x7ffffcad3100)
at /build/src/tdelibs/kate/part/katelinerange.h:25
25 /build/src/tdelibs/kate/part/katelinerange.h: No such file or directory.
(gdb) bt
#0 0x00007f1723b65947 in KateLineRange (this=0x7ffffcad3100)
at /build/src/tdelibs/kate/part/katelinerange.h:25
#1 KateViewInternal::range (this=this@entry=0x152c5d0, realLine=realLine@entry=4,
previous=previous@entry=0x0)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1308
#2 0x00007f1723b66b32 in KateViewInternal::range (this=this@entry=0x152c5d0,
realLine=4, viewLine=viewLine@entry=1)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1418
#3 0x00007f1723b66fd3 in KateViewInternal::nextRange (this=this@entry=0x152c5d0)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1391
#4 0x00007f1723b6ec7f in KateViewInternal::cursorDown (this=0x152c5d0, sel=false)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1772
#5 0x00007f1723b4bc9c in KateView::tqt_invoke (this=0x173dac0, _id=172,
_o=0x7ffffcad3370) at /build/src/build/kate/part/kateview.moc:772
#6 0x00007f17299d0d35 in TQObject::activate_signal (this=0x16805c0,
clist=0x14729f0,
o=0x7ffffcad3370) at kernel/qobject.cpp:2383
#7 0x00007f17299d0bbb in TQObject::activate_signal (this=0x16805c0, signal=2)
at kernel/qobject.cpp:2352
#8 0x00007f172ba21a24 in KAction::tqt_invoke (this=0x16805c0, _id=15,
_o=0x7ffffcad3480) at /build/src/build/tdeui/kaction.moc:216
#9 0x00007f17299d0d35 in TQObject::activate_signal (this=0x172ae50,
clist=0x16d2780,
o=0x7ffffcad3480) at kernel/qobject.cpp:2383
#10 0x00007f17299d0bbb in TQObject::activate_signal (this=0x172ae50, signal=2)
at kernel/qobject.cpp:2352
#11 0x00007f172a9bacc5 in KAccelPrivate::emitActivatedSignal (
this=this@entry=0x172ae50, pAction=0x14b2fa0)
at /build/src/tdelibs/tdecore/kaccel.cpp:403
#12 0x00007f172a9bc8db in KAccelPrivate::eventFilter (this=0x172ae50, pEvent=
0x7ffffcad3ab0) at /build/src/tdelibs/tdecore/kaccel.cpp:373
#13 0x00007f17299ce4cc in TQObject::activate_filters (this=0x152c5d0,
e=0x7ffffcad3ab0) at kernel/qobject.cpp:930
#14 0x00007f17299ce326 in TQObject::event (this=0x152c5d0, e=0x7ffffcad3ab0)
at kernel/qobject.cpp:762
#15 0x00007f1729a06237 in TQWidget::event (this=0x152c5d0, e=0x7ffffcad3ab0)
at kernel/qwidget.cpp:4701
#16 0x00007f1729970559 in TQApplication::internalNotify (this=0x7ffffcad4170,
receiver=0x152c5d0, e=0x7ffffcad3ab0) at kernel/qapplication.cpp:2638
#17 0x00007f172996f9eb in TQApplication::notify (this=0x7ffffcad4170,
receiver=0x152c5d0, e=0x7ffffcad3ab0) at kernel/qapplication.cpp:2395
---Type <return> to continue, or q <return> to quit---
#18 0x00007f172a92a844 in KApplication::notify (this=0x7ffffcad4170,
receiver=0x152c5d0, event=0x7ffffcad3ab0)
at /build/src/tdelibs/tdecore/kapplication.cpp:583
#19 0x00007f172a9b8f88 in sendEvent (event=0x7ffffcad3ab0, receiver=<optimized
out>)
at /opt/tqt3/include/ntqapplication.h:523
#20 KAccelEventHandler::x11Event (this=<optimized out>, pEvent=<optimized
out>)
at /build/src/tdelibs/tdecore/kaccel.cpp:147
#21 0x00007f172a92c5a8 in publicx11Event (e=0x7ffffcad3e20, this=<optimized out>)
at /build/src/tdelibs/tdecore/kapplication.cpp:1782
#22 KApplication::x11EventFilter (this=0x7ffffcad4170, _event=0x7ffffcad3e20)
at /build/src/tdelibs/tdecore/kapplication.cpp:2094
#23 0x00007f17298ef48f in qt_x11EventFilter (ev=0x7ffffcad3e20)
at kernel/qapplication_x11.cpp:422
#24 0x00007f17298f929a in TQApplication::x11ProcessEvent (this=0x7ffffcad4170,
event=0x7ffffcad3e20) at kernel/qapplication_x11.cpp:3422
#25 0x00007f1729914c44 in TQEventLoop::processEvents (this=0x1378ec0, flags=4)
at kernel/qeventloop_x11.cpp:195
#26 0x00007f1729983818 in TQEventLoop::enterLoop (this=0x1378ec0)
at kernel/qeventloop.cpp:201
#27 0x00007f17299836e9 in TQEventLoop::exec (this=0x1378ec0)
at kernel/qeventloop.cpp:148
#28 0x00007f1729970689 in TQApplication::exec (this=0x7ffffcad4170)
at kernel/qapplication.cpp:2761
#29 0x00007f172dc5f3a8 in kdemain (argc=1, argv=0x7ffffcad4748)
at /build/src/tdebase/kate/app/kwritemain.cpp:692
#30 0x000000000040082c in main (argc=1, argv=0x7ffffcad4748)
at /build/src/build/kate/app/kwrite_tdeinit_executable.cpp:2
(gdb)
--
David C. Rankin, J.D.,P.E.
3 May
3 May
1:13 a.m.
New subject: [trinity-devel] kwrite Crash - Now Down To 3/29 -> 4/1 (this may not be good -- gcc to blame?)
Tim, Darrell, All:
I rebuilt TDE from 4/1 sources with full debug in attempt to further
look into
the kwrite crash that Darrell and I have experienced with TDE built on gcc
4.7.
With this build, if it is a source/bad patch/tde issue, then with my 3/29
build
giving no crash and my 4/1 build crashing, that would point to some
problem in
between those two dates. However, I am coming around to the thought that
-- this
isn't a TDE problem and is more likely a problem introduced by the gcc 4.7
interpretation of the TDE code. I will still have to build the 3/29
sources with
gcc 4.7 to confirm that to be the case. I have 3/29 binaries that work
fine
(which I'm fairly sure were built on gcc 4.7, but I can't remember). If I
rebuild with gcc47 on the 3/29 sources and get the same failure -- that,
in my
mind, conclusively points to the problem being gcc47.
If that is the case -- how in the heck do you debug something like that?
Upgrading gcc should NOT cause working code to start crashing unless the
C/C++ standard was violated somewhere. As ugly as it may be, we may need
to entertain the notion that gcc 4.7 is actually generating buggy code (it
would not be the first time, IIRC gcc 4.3 caused crashes as well that were
magically resolved with gcc 4.4).
That said, I hope you find something soon and that this is NOT a gcc
related issue!
Tim
1:15 a.m.
New subject: [trinity-devel] kwrite Crash - Now Down To 3/29 -> 4/1 (this may not be good -- gcc to blame?)
Tim, Darrell,
All:
I rebuilt TDE from 4/1 sources with full debug in attempt to further
look into
the kwrite crash that Darrell and I have experienced with TDE built on
gcc
4.7.
With this build, if it is a source/bad patch/tde issue, then with my
3/29
build
giving no crash and my 4/1 build crashing, that would point to some
problem in
between those two dates. However, I am coming around to the thought that
-- this
isn't a TDE problem and is more likely a problem introduced by the gcc
4.7
interpretation of the TDE code. I will still have to build the 3/29
sources with
gcc 4.7 to confirm that to be the case. I have 3/29 binaries that work
fine
(which I'm fairly sure were built on gcc 4.7, but I can't remember). If
I
rebuild with gcc47 on the 3/29 sources and get the same failure -- that,
in my
mind, conclusively points to the problem being gcc47.
If that is the case -- how in the heck do you debug something like
that?
Upgrading gcc should NOT cause working code to start crashing unless the
C/C++ standard was violated somewhere. As ugly as it may be, we may need
to entertain the notion that gcc 4.7 is actually generating buggy code (it
would not be the first time, IIRC gcc 4.3 caused crashes as well that were
magically resolved with gcc 4.4).
That said, I hope you find something soon and that this is NOT a gcc
related issue!
Tim
2:08 a.m.
New subject: [trinity-devel] kwrite Crash - Now Down To 3/29 -> 4/1 (this may not be good -- gcc to blame?)
On 05/02/2012 08:13 PM, Timothy Pearson wrote:
That said, I hope you find something soon and that
this is NOT a gcc
related issue!
Grumble, grumble, grumble -- Uh, Boss... I've got bad news...
--
David C. Rankin, J.D.,P.E.
5:59 a.m.
New subject: [trinity-devel] kwrite Crash - Now Down To 3/29 -> 4/1 (this may not be good -- gcc to blame?)
On 05/02/2012 08:13 PM, Timothy Pearson wrote:
Before I chase a wild goose, any chance you can verify with a rebuild of
the latest GIT head on gcc 4.6?
Tim
That said, I hope you find something soon and
that this is NOT a gcc
related issue!
Grumble, grumble, grumble -- Uh, Boss... I've got bad news...
--
David C. Rankin, J.D.,P.E.
12:40 p.m.
New subject: [trinity-devel] kwrite Crash - Now Down To 3/29 -> 4/1 (this may not be good -- gcc to blame?)
On 05/03/2012 12:59 AM, Timothy Pearson wrote:
Yep, I'm glad to do it. right now I have marching orders for:
(1) gcc46 build
(2) g++ -S -fverbose-asm -I??? <FLAGS> katerenderer.cpp
(3) valgrind of kwrite
Which I'll probably do in reverse order since I've already got the failing
binaries loaded.
--
David C. Rankin, J.D.,P.E.
On 05/02/2012
08:13 PM, Timothy Pearson wrote:
Before I chase a wild goose, any chance you can verify with a rebuild of
the latest GIT head on gcc 4.6?
Tim
That said, I hope you find something soon and
that this is NOT a gcc
related issue!
Grumble, grumble, grumble -- Uh, Boss... I've got bad news...
--
David C. Rankin, J.D.,P.E. 
9:43 a.m.
New subject: [trinity-devel] kwrite Crash - Now Down To 3/29 -> 4/1 (this may not be good -- gcc to blame?)
On 3 May 2012, Timothy Pearson told this:
As ugly as it
may be, we may need
to entertain the notion that gcc 4.7 is actually generating buggy code (it
would not be the first time,
Well, yeah. GCC 4.7 is still quite new. There is a reason the GCC
bugzilla has a class of bugs named 'wrong-code'...
If only I'd not fat-fingered and blown away my git repos I could help
looking into that backtrace, but I did and I haven't restored from
backup yet.
--
NULL && (void)
4387
days inactive
4388
days old
6 comments
3 participants
participants (3)
-
David C. Rankin -
Nix -
Timothy Pearson