bugs.kde.org is down so I figured I'll ask here.

I can add a feed with no issues.
I can create a filter with no issues.
But if I try to add that filter to that feed, I get a crash as soon as I hit that left arrow to move it from the right list into the left list. Funnily enough when the app comes back up, the filter is no longer there so I have to enter it all over again.

Unfortunately it looks like there isn't enough info in the crash dump... for whatever reason the ktorrent ebuild doesn't pay attention to the debug flag...

But maybe someone else has seen the same issue, which would be enough comfort for me.

Code: Select all

Thread 3 (Thread 0xb425fb90 (LWP 19612)):
#0  0xffffe410 in ?? ()
#1  0xb425f3a8 in ?? ()
#2  0xb6417ff4 in ?? () from /usr/lib/libbtcore.so.8
#3  0x00000000 in ?? ()

Thread 2 (Thread 0xb33a2b90 (LWP 19613)):
#0  0xffffe410 in ?? ()
#1  0xb33a2318 in ?? ()
#2  0x00000031 in ?? ()
#3  0x00000000 in ?? ()

Thread 1 (Thread 0xb590f6d0 (LWP 19606)):
#0  0xffffe410 in ?? ()
#1  0xbfe22098 in ?? ()
#2  0xb5da3ff4 in ?? () from /lib/libc.so.6
#3  0xbfe22084 in ?? ()
#4  0xb5d05866 in nanosleep () from /lib/libc.so.6
#5  0xb5d0568b in sleep () from /lib/libc.so.6
#6  0xb6debd11 in KCrash::startDrKonqi (argv=0xbfe24238, argc=17)
    at /var/tmp/portage/kde-base/kdelibs-4.1.3-r1/work/kdelibs-4.1.3/kdeui/util/kcrash.cpp:412
#7  0xb6dec558 in KCrash::defaultCrashHandler (sig=6)
    at /var/tmp/portage/kde-base/kdelibs-4.1.3-r1/work/kdelibs-4.1.3/kdeui/util/kcrash.cpp:337
#8  0xffffe420 in ?? ()
#9  0x00000006 in ?? ()
#10 0x00000033 in ?? ()
#11 0x00000000 in ?? ()
#0  0xffffe410 in ?? ()


I can't reproduce it, gonna need a better backtrace to figure this out.

George wrote:I can't reproduce it, gonna need a better backtrace to figure this out.

Along those lines, what is the magic flag to get ktorrent's build to not strip the debug information out? I created a clone of the ebuild but it isn't obvious how to change that setting. I already have "nostrip" in my features globally.

Here's my latest futile attempt anyway, it shows more but it's not necessarily in the thread causing the problem.

Code: Select all

Application: KTorrent (ktorrent), signal SIGABRT
Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 0xb58f36d0 (LWP 11210)]
[New Thread 0xb3369b90 (LWP 11215)]
[New Thread 0xb423db90 (LWP 11214)]
0xffffe410 in ?? ()
[Current thread is 0 (LWP 11210)]

Thread 3 (Thread 0xb423db90 (LWP 11214)):
#0  0xffffe410 in ?? ()
#1  0x080fbab0 in ?? ()
#2  0xb6435ff4 in ?? () from /usr/lib/libbtcore.so.8
#3  0x00000000 in ?? ()

Thread 2 (Thread 0xb3369b90 (LWP 11215)):
#0  0xffffe410 in ?? ()
#1  0xb33692f8 in ?? ()
#2  0x00000011 in ?? ()
#3  0x080fc0a8 in ?? ()
#4  0xb33692e8 in ?? ()
#5  0xb7c86957 in QMutexPrivate::self (this=0x80fbe20)
    at thread/qmutex_unix.cpp:77
#6  0xb6357fad in net::UploadThread::update (this=0x80fbde8)
    at /var/tmp/portage/net-p2p/ktorrent-3.2_beta1/work/ktorrent-3.2beta1/libbtcore/net/uploadthread.cpp:73
#7  0xb635a6b8 in net::NetworkThread::run (this=0x80fbde8)
    at /var/tmp/portage/net-p2p/ktorrent-3.2_beta1/work/ktorrent-3.2beta1/libbtcore/net/networkthread.cpp:48
#8  0xb7c874ce in QThreadPrivate::start (arg=0x80fbde8)
    at thread/qthread_unix.cpp:191
#9  0xb7c0c18b in start_thread () from /lib/libpthread.so.0
#10 0xb5d1d04e in clone () from /lib/libc.so.6

Thread 1 (Thread 0xb58f36d0 (LWP 11210)):
#0  0xffffe410 in ?? ()
#1  0xbff9b1c8 in ?? ()
#2  0xb5d87ff4 in ?? () from /lib/libc.so.6
#3  0xbff9b1b4 in ?? ()
#4  0xb5ce9866 in nanosleep () from /lib/libc.so.6
#5  0xb5ce968b in sleep () from /lib/libc.so.6
#6  0xb6e0bd11 in KCrash::startDrKonqi (argv=0xbff9d368, argc=17)
    at /var/tmp/portage/kde-base/kdelibs-4.1.3-r1/work/kdelibs-4.1.3/kdeui/util/kcrash.cpp:412
#7  0xb6e0c558 in KCrash::defaultCrashHandler (sig=6)
    at /var/tmp/portage/kde-base/kdelibs-4.1.3-r1/work/kdelibs-4.1.3/kdeui/util/kcrash.cpp:337
#8  0xffffe420 in ?? ()
#9  0x00000006 in ?? ()
#10 0x00000000 in ?? ()
#0  0xffffe410 in ?? ()


If the remaining bits are part of another library, I need to somehow figure out which library it is, in order to know which one is misbehaving.

trejkaz wrote:

George wrote:I can't reproduce it, gonna need a better backtrace to figure this out.

Along those lines, what is the magic flag to get ktorrent's build to not strip the debug information out? I created a clone of the ebuild but it isn't obvious how to change that setting. I already have "nostrip" in my features globally.

The cmake option is -DCMAKE_BUILD_TYPE=debugfull

How about compiling it manually ?

OK, here's what we get after adding that:

Code: Select all

Application: KTorrent (ktorrent), signal SIGABRT
Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 0xb59016d0 (LWP 22397)]
[New Thread 0xb30e3b90 (LWP 22401)]
[New Thread 0xb424bb90 (LWP 22400)]
0xffffe410 in ?? ()
[Current thread is 0 (LWP 22397)]

Thread 3 (Thread 0xb424bb90 (LWP 22400)):
#0  0xb6366d7e in std::vector<pollfd, std::allocator<pollfd> >::operator[] (
    this=0x80faae8, __n=27)
    at /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/stl_vector.h:480
#1  0xb636652a in net::DownloadThread::waitForSocketReady (this=0x80faab0,
    timeout=50)
    at /var/tmp/portage/net-p2p/ktorrent-3.2_beta1/work/ktorrent-3.2beta1/libbtcore/net/downloadthread.cpp:140
#2  0xb63665be in net::DownloadThread::update (this=0x80faab0)
    at /var/tmp/portage/net-p2p/ktorrent-3.2_beta1/work/ktorrent-3.2beta1/libbtcore/net/downloadthread.cpp:51
#3  0xb6368308 in net::NetworkThread::run (this=0x80faab0)
    at /var/tmp/portage/net-p2p/ktorrent-3.2_beta1/work/ktorrent-3.2beta1/libbtcore/net/networkthread.cpp:48
#4  0xb7c944ce in QThreadPrivate::start (arg=0x80faab0)
    at thread/qthread_unix.cpp:191
#5  0xb7c1918b in start_thread () from /lib/libpthread.so.0
#6  0xb5d2b04e in clone () from /lib/libc.so.6

Thread 2 (Thread 0xb30e3b90 (LWP 22401)):
#0  0xffffe410 in ?? ()
#1  0xb30e32f8 in ?? ()
#2  0x00000013 in ?? ()
#3  0x080fb0a8 in ?? ()
#4  0xb30e32e8 in ?? ()
#5  0xb7c93957 in QMutexPrivate::self (this=0x80fae20)
    at thread/qmutex_unix.cpp:77
#6  0xb6365b7c in net::UploadThread::update (this=0x80fade8)
    at /var/tmp/portage/net-p2p/ktorrent-3.2_beta1/work/ktorrent-3.2beta1/libbtcore/net/uploadthread.cpp:73
#7  0xb6368308 in net::NetworkThread::run (this=0x80fade8)
    at /var/tmp/portage/net-p2p/ktorrent-3.2_beta1/work/ktorrent-3.2beta1/libbtcore/net/networkthread.cpp:48
#8  0xb7c944ce in QThreadPrivate::start (arg=0x80fade8)
    at thread/qthread_unix.cpp:191
#9  0xb7c1918b in start_thread () from /lib/libpthread.so.0
#10 0xb5d2b04e in clone () from /lib/libc.so.6

Thread 1 (Thread 0xb59016d0 (LWP 22397)):
#0  0xffffe410 in ?? ()
#1  0xbfa52478 in ?? ()
#2  0xb5d95ff4 in ?? () from /lib/libc.so.6
#3  0xbfa52464 in ?? ()
#4  0xb5cf7866 in nanosleep () from /lib/libc.so.6
#5  0xb5cf768b in sleep () from /lib/libc.so.6
#6  0xb6e18d11 in KCrash::startDrKonqi (argv=0xbfa54618, argc=17)
    at /var/tmp/portage/kde-base/kdelibs-4.1.3-r1/work/kdelibs-4.1.3/kdeui/util/kcrash.cpp:412
#7  0xb6e19558 in KCrash::defaultCrashHandler (sig=6)
    at /var/tmp/portage/kde-base/kdelibs-4.1.3-r1/work/kdelibs-4.1.3/kdeui/util/kcrash.cpp:337
#8  0xffffe420 in ?? ()
#9  0x00000006 in ?? ()
#10 0x00000000 in ?? ()
#0  0xffffe410 in ?? ()