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)
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
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
That should read that gcc 4.4, not 4.3, was a problem.
http://old.nabble.com/KDE-3.5.10-konqueror-and-gcc-4.4.0-td23626025.html
Tim
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...
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.
Before I chase a wild goose, any chance you can verify with a rebuild of the latest GIT head on gcc 4.6?
Tim
On 05/03/2012 12:59 AM, Timothy Pearson wrote:
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.
Before I chase a wild goose, any chance you can verify with a rebuild of the latest GIT head on gcc 4.6?
Tim
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.
On 3 May 2012, Timothy Pearson told this:
As ugly as it may be, we may needto 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.
-
David C. Rankin -
Nix -
Timothy Pearson