Tim, Darrell, All,
I rebuilt all packages this morning with sources from 4/3 to help narrow down the kwrite crash issue. The files were built with full debug information. I don't know if this new backtrace is useful, but it is different from the prior backtraces in that it points straight at tqt3. (at least to me) I can't interpret exactly what it is saying, but I'll let the experts decide:
Loaded symbols for /lib/libnss_files.so.2 0xb69ebb20 in __x86.get_pc_thunk.bx () from /opt/tqt3/lib/libtqt-mt.so.3 (gdb) bt #0 0xb69ebb20 in __x86.get_pc_thunk.bx () from /opt/tqt3/lib/libtqt-mt.so.3 #1 0xb6a12d77 in category (c=...) at ../include/private/qunicodetables_p.h:99 #2 0xb6d89361 in isSpace (ch=...) at tools/qunicodetables_p.h:218 #3 0xb6d7e96f in TQChar::isSpace (this=0x8d8d810) at tools/qstring.cpp:475 #4 0xb5270346 in KateRenderer::textWidth (this=0x8b4e400, textLine=..., startcol=0, maxwidth=751, needWrap=0xbfae53d8, endX=0xbfae53cc) at /build/src/tdelibs/kate/part/katerenderer.cpp:806 #5 0xb524dd97 in KateViewInternal::range (this=0x8bc5e20, realLine=0, previous=0x0) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1331 #6 0xb524f1ae in KateViewInternal::range (this=0x8bc5e20, realLine=0, viewLine=1) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1418 #7 0x08bc5e20 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?)
A strace was also run and I've attached that to bug 979.
http://bugs.pearsoncomputing.net/attachment.cgi?id=576
I also get a lot of undefined symbol messages when strace is running. I don't know if this will help, but maybe it provides a clue. IIRC, there was a name mangling patch that went it at some time around here. This is what gets dumped to konsole:
13:52 tdepv:~> strace -o vbh/tde/err/kwrite/strace0403.txt kwrite /opt/tqt3/plugins/inputmethods/libqimsw-multi.so: undefined symbol: _ZN14TQInputContext11sendIMEventEN7TQEvent4TypeERK8TQStringii /opt/tqt3/plugins/inputmethods/libqsimple.so: undefined symbol: _ZN14TQInputContext14x11FilterEventEP8TQWidgetP7_XEvent /opt/tqt3/plugins/inputmethods/libqxim.so: undefined symbol: _ZN14TQInputContext11filterEventEPK7TQEvent /opt/tqt3/plugins/inputmethods/libqimsw-multi.so: undefined symbol: _ZN14TQInputContext11sendIMEventEN7TQEvent4TypeERK8TQStringii /opt/tqt3/plugins/inputmethods/libqsimple.so: undefined symbol: _ZN14TQInputContext14x11FilterEventEP8TQWidgetP7_XEvent /opt/tqt3/plugins/inputmethods/libqxim.so: undefined symbol: _ZN14TQInputContext11filterEventEPK7TQEvent /opt/tqt3/plugins/inputmethods/libqimsw-multi.so: undefined symbol: _ZN14TQInputContext11sendIMEventEN7TQEvent4TypeERK8TQStringii /opt/tqt3/plugins/inputmethods/libqsimple.so: undefined symbol: _ZN14TQInputContext14x11FilterEventEP8TQWidgetP7_XEvent /opt/tqt3/plugins/inputmethods/libqxim.so: undefined symbol: _ZN14TQInputContext11filterEventEPK7TQEvent /opt/tqt3/plugins/inputmethods/libqimsw-multi.so: undefined symbol: _ZN14TQInputContext11sendIMEventEN7TQEvent4TypeERK8TQStringii /opt/tqt3/plugins/inputmethods/libqsimple.so: undefined symbol: _ZN14TQInputContext14x11FilterEventEP8TQWidgetP7_XEvent /opt/tqt3/plugins/inputmethods/libqxim.so: undefined symbol: _ZN14TQInputContext11filterEventEPK7TQEvent <snip> (see attached file for remainder)
I also tested kate - same crash! I don't know what Darrell is doing, he must be living right! I just pasted 'undefined symbol ' into line one until it would make it wrap and then on the next paste - wham! > crashed. This backtrace is a bit different, the qt3 error I saw in kwrite appears masked for some reason?? Here is the kate crash backtrace:
Loaded symbols for /opt/tqt3/plugins/inputmethods/libqimsw-none.so 0xb620dd36 in TQChar::row (this=0x9f4c300) at ../include/ntqstring.h:221 221 ../include/ntqstring.h: No such file or directory. (gdb) bt #0 0xb620dd36 in TQChar::row (this=0x9f4c300) at ../include/ntqstring.h:221 #1 0xb620dd88 in category (c=...) at ../include/private/qunicodetables_p.h:104 #2 0xb6584361 in isSpace (ch=...) at tools/qunicodetables_p.h:218 #3 0xb657996f in TQChar::isSpace (this=0x9f4c300) at tools/qstring.cpp:475 #4 0xb5503346 in KateRenderer::textWidth (this=0x9fc6260, textLine=..., startcol=0, maxwidth=555, needWrap=0xbf887a08, endX=0xbf8879fc) at /build/src/tdelibs/kate/part/katerenderer.cpp:806 #5 0xb54e0d97 in KateViewInternal::range (this=0xa08e128, realLine=0, previous=0x0) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1331 #6 0xb54e21ae in KateViewInternal::range (this=0xa08e128, realLine=0, viewLine=1) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1418 #7 0x0a08e128 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?)
What say the experts? Anything look like it points to anything specific? Worth running a strace on kate?
I also found another bug in the setup wizard when choosing keramik style -- you get no window decorations. (this may be fixed since this was the 4/3 code). Plastik works fine. I had deleted ksycoca and my ~/.trinity profile for this test, so I was starting over from scratch. I thought I would pass that along as well.
On 05/01/2012 02:12 PM, David C. Rankin wrote:
I also tested kate - same crash! I don't know what Darrell is doing, he must be living right! I just pasted 'undefined symbol ' into line one until it would make it wrap and then on the next paste - wham! > crashed. This backtrace is a bit different, the qt3 error I saw in kwrite appears masked for some reason?? Here is the kate crash backtrace:
This time I just opened an existing file in kate (my .bashrc). I was able to view it and resize the window, but when I started moving the cursor down the page with 'down-arrow' it locked up about 10 lines down. I don't think this backtrace adds anything, but it's short. The one thing that sticks out to me is the 'needWrap' variable. It may be nothing, but that seems to be common to the crashes:
KateRenderer::textWidth (this=0x9e0b2e0, textLine=..., startcol=0, maxwidth=681, needWrap=0xbfe297f8, endX=0xbfe297ec) at /build/src/tdelibs/kate/part/katerenderer.cpp:794 794 /build/src/tdelibs/kate/part/katerenderer.cpp: No such file or directory. (gdb) bt #0 KateRenderer::textWidth (this=0x9e0b2e0, textLine=..., startcol=0, maxwidth=681, needWrap=0xbfe297f8, endX=0xbfe297ec) at /build/src/tdelibs/kate/part/katerenderer.cpp:794 #1 0xb542bd97 in KateViewInternal::range (this=0x9df5478, realLine=20, previous=0x0) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1331 #2 0xb542d1ae in KateViewInternal::range (this=0x9df5478, realLine=20, viewLine=1) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1418 #3 0x00000001 in ?? () #4 0xb542d6cb in KateViewInternal::nextRange (this=0x9df5478) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1391 #5 0x00000014 in ?? () #6 0xb543791b in KateViewInternal::cursorDown (this=0xb54ea3fc, sel=false) at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1772 #7 0xbfe29a78 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?)
The same undefined symbol output continues in konsole:
<snip> /opt/tqt3/plugins/inputmethods/libqimsw-multi.so: undefined symbol: _ZN14TQInputContext11sendIMEventEN7TQEvent4TypeERK8TQStringii /opt/tqt3/plugins/inputmethods/libqsimple.so: undefined symbol: _ZN14TQInputContext14x11FilterEventEP8TQWidgetP7_XEvent /opt/tqt3/plugins/inputmethods/libqxim.so: undefined symbol: _ZN14TQInputContext11filterEventEPK7TQEvent /opt/tqt3/plugins/inputmethods/libqimsw-multi.so: undefined symbol: _ZN14TQInputContext11sendIMEventEN7TQEvent4TypeERK8TQStringii /opt/tqt3/plugins/inputmethods/libqsimple.so: undefined symbol: _ZN14TQInputContext14x11FilterEventEP8TQWidgetP7_XEvent /opt/tqt3/plugins/inputmethods/libqxim.so: undefined symbol: _ZN14TQInputContext11filterEventEPK7TQEvent /opt/tqt3/plugins/inputmethods/libqimsw-multi.so: undefined symbol: _ZN14TQInputContext11sendIMEventEN7TQEvent4TypeERK8TQStringii /opt/tqt3/plugins/inputmethods/libqsimple.so: undefined symbol: _ZN14TQInputContext14x11FilterEventEP8TQWidgetP7_XEvent /opt/tqt3/plugins/inputmethods/libqxim.so: undefined symbol: _ZN14TQInputContext11filterEventEPK7TQEvent
IIRC, Tim, you said the undefined symbol stuff is normal?
On 05/01/2012 02:12 PM, David C. Rankin wrote:
I also tested kate - same crash! I don't know what Darrell is doing, he must be living right! I just pasted 'undefined symbol ' into line one until it would make it wrap and then on the next paste - wham! > crashed. This backtrace is a bit different, the qt3 error I saw in kwrite appears masked for some reason?? Here is the kate crash backtrace:
This time I just opened an existing file in kate (my .bashrc). I was able to view it and resize the window, but when I started moving the cursor down the page with 'down-arrow' it locked up about 10 lines down. I don't think this backtrace adds anything, but it's short. The one thing that sticks out to me is the 'needWrap' variable. It may be nothing, but that seems to be common to the crashes:
<snip>
IIRC, Tim, you said the undefined symbol stuff is normal?
I don't remember saying that. :-) The undefined symbols would explain why your backtraces are lacking TQt3 line numbers, without which debugging is nearly impossible.
If this really is a [T]Qt3 problem, you should be able to revert to an earlier version and the crash should disappear. However, I see nothing in the log that is close to the timeframe in question, and most of the patches for the past several months have been trivial:
http://git.trinitydesktop.org/cgit/qt3/log/
I have not yet tried to replicate this bug on any systems here. You said you are running this in a VirtualBox session, correct? If so, be aware that I have run into "TDE bugs" (crashes) before that actually turn out to be VirtualBox bugs...
Tim
On 05/01/2012 02:34 PM, Timothy Pearson wrote:
I have not yet tried to replicate this bug on any systems here. You said you are running this in a VirtualBox session, correct? If so, be aware that I have run into "TDE bugs" (crashes) before that actually turn out to be VirtualBox bugs...
Tim
Yes,
That's why I was comforted that this wasn't the case when Darrell ran into it on a real box. So while the virtualbox variable is something to be aware of, it has real box confirmation as well. I'm guessing that it was tqt base on the first backtrace I caught today:
0xb69ebb20 in __x86.get_pc_thunk.bx () from /opt/tqt3/lib/libtqt-mt.so.3 (gdb) bt #0 0xb69ebb20 in __x86.get_pc_thunk.bx () from /opt/tqt3/lib/libtqt-mt.so.3 #1 0xb6a12d77 in category (c=...) at ../include/private/qunicodetables_p.h:99 #2 0xb6d89361 in isSpace (ch=...) at tools/qunicodetables_p.h:218
I have no idea what a 'get_pc_thunk.bx' is other than I thunk I'll get another pc too to speed up building :) I guess it is talking about the bx register...
That's why I just reported and pointed out the libtqt-mt.so.3 part of the crash at the top (which looked like it pointed to tqt3 to me -- that's just me guessing though)
I've read through the patch list, and again today in the 3/29 - 4/3 timeframe. I don't see anything that looks related by title either, but I don't know what all is getting changed. We'll keep picking on it.
On Tue, 01 May 2012 16:04:18 -0500 "David C. Rankin" drankinatty@suddenlinkmail.com wrote:
On 05/01/2012 02:34 PM, Timothy Pearson wrote:
I have not yet tried to replicate this bug on any systems here. You said you are running this in a VirtualBox session, correct? If so, be aware that I have run into "TDE bugs" (crashes) before that actually turn out to be VirtualBox bugs...
Tim
Yes,
That's why I was comforted that this wasn't the case when Darrell ran into it on a real box. So while the virtualbox variable is something to be aware of, it has real box confirmation as well. I'm guessing that it was tqt base on the first backtrace I caught today:
0xb69ebb20 in __x86.get_pc_thunk.bx () from /opt/tqt3/lib/libtqt-mt.so.3 (gdb) bt #0 0xb69ebb20 in __x86.get_pc_thunk.bx () from /opt/tqt3/lib/libtqt-mt.so.3 #1 0xb6a12d77 in category (c=...) at ../include/private/qunicodetables_p.h:99 #2 0xb6d89361 in isSpace (ch=...) at tools/qunicodetables_p.h:218
I have no idea what a 'get_pc_thunk.bx' is other than I thunk I'll get another pc too to speed up building :) I guess it is talking about the bx register...
It loads the position of the calling code in the %ebx register: http://stackoverflow.com/questions/6679846/what-is-i686-get-pc-thunk-bx-why-...
That's why I just reported and pointed out the libtqt-mt.so.3 part of the crash at the top (which looked like it pointed to tqt3 to me -- that's just me guessing though)
I've read through the patch list, and again today in the 3/29 - 4/3 timeframe. I don't see anything that looks related by title either, but I don't know what all is getting changed. We'll keep picking on it.
-
/dev/ammo42 -
David C. Rankin -
Timothy Pearson