On Thu, 26 Apr 2012 11:26:08 -0500
"David C. Rankin" <drankinatty(a)suddenlinkmail.com> wrote:
On 04/26/2012 11:13 AM, David C. Rankin wrote:
On 04/26/2012 08:01 AM, David C. Rankin wrote:
I'll open a bug report shortly :)
Good Lord! Debug Packages are HUGE!!!
Nearly 600M of debugging symbols included in tqt3, tqtinterface,
tdelibs, tdebase. It looks like with will have to do this again on
x86_64, the i686 backtrace seems to stop early. However, it does
have line numbers for everything it caught:
(gdb) bt
#0 0xb610a959 in TQFontMetrics::charWidth (this=0x8fa3800, str=...,
pos=79) at kernel/qfont_x11.cpp:705
#1 0xb541a46b in width (tabWidth=8, italic=false, bold=false,
col=79, text=..., this=0x8fa37f0)
at /build/src/tdelibs/kate/part/katefont.h:76
#2 width (tabWidth=8, col=79, text=..., fs=..., this=<optimized
out>) at /build/src/tdelibs/kate/part/kateattribute.h:55
#3 KateRenderer::textWidth (this=0x933d3e8, textLine=...,
startcol=0, maxwidth=695,
needWrap=0xbf8e73a8, endX=0xbf8e739c) at
/build/src/tdelibs/kate/part/katerenderer.cpp:797
#4 0xb53f7d97 in KateViewInternal::range (this=0x9322170,
realLine=0, previous=0x0)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1331
#5 0xb53f91ae in KateViewInternal::range (this=0x9322170,
realLine=0, viewLine=1)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1418 #6
0x09322170 in ?? () Backtrace stopped: previous frame inner to this
frame (corrupt stack?)
I have opened a bug report and added this information to it:
http://bugs.trinitydesktop.org/show_bug.cgi?id=979
"select buffer paste in kate/kwrite causing line wrap causes crash
(X, qt3)"
Do you want me to begin a debug build on x86_64 as well? I can't
tell if this is enough of a backtrace to provide you with the
needed info. Let me know what else you need. Thanks!
Tim,
This is much worse than we thought. It effects EVERYTHING! Even
simply trying to view a text file in konqueror file management (kate
preview) will lock konqueror. Here is that backtrace too:
(gdb) bt
#0 0xb777f416 in __kernel_vsyscall ()
#1 0xb65154ed in ___newselect_nocancel () from /lib/libc.so.6
#2 0xb7466f56 in KIO::SlaveBase::dispatchLoop (this=0xbfae15b8)
at /build/src/tdelibs/kio/kio/slavebase.cpp:286
#3 0xb7770fa6 in kdemain (argc=4, argv=0xbfae15b8) at
/build/src/tdelibs/kioslave/file/file.cc:128
#4 0x080503c1 in launch (argc=4, _name=0x8bc09b4 "kio_file",
args=0xbfae1784 "\300\216\367\266",
cwd=0x0, envc=0, envs=0x8bc0a2a "", reset_env=false, tty=0x0,
avoid_loops=false,
startup_id_str=0xfffffdfe <Address 0xfffffdfe out of bounds>,
startup_id_str@entry=0x4 <Address 0x4 out of bounds>) at
/build/src/tdelibs/kinit/kinit.cpp:673
#5 0x0805148c in handle_launcher_request (sock=<optimized out>,
sock@entry=-1) at /build/src/tdelibs/kinit/kinit.cpp:1240
#6 0x08051a0a in handle_requests (waitForPid=waitForPid@entry=0)
at /build/src/tdelibs/kinit/kinit.cpp:1443
#7 0x0804d775 in main (argc=5, argv=0xbfae1d54, envp=0xbfae1d6c)
at /build/src/tdelibs/kinit/kinit.cpp:1908
Bummer... Think about what other tests I can do that might
disclose exactly what it going south...
In my glibc-2.11 binary the objdump output tells me that
___newselect_nocancel() always does a syscall (you can recognise them
by the "int $0x80" instruction), so you should be able to retrieve the
parameters with strace.