Version: unspecified (using KDE 4.5.5) OS: Linux Application: KTorrent (ktorrent), signal: Segmentation fault [Current thread is 1 (Thread 0xb7866ab0 (LWP 14389))] Thread 5 (Thread 0xb589eb70 (LWP 14461)): #0 0x00268416 in __kernel_vsyscall () #1 0x00cf239b in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S:169 #2 0x41e85057 in WTF::TCMalloc_PageHeap::runScavengerThread(void*) () from /usr/lib/libQtWebKit.so.4 #3 0x00cede99 in start_thread (arg=0xb589eb70) at pthread_create.c:301 #4 0x00c2cd2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133 Thread 4 (Thread 0xaf3aeb70 (LWP 14621)): #0 0x00268416 in __kernel_vsyscall () #1 0x00be1ca6 in gettimeofday () at ../sysdeps/unix/syscall-template.S:82 #2 0x04c3e705 in bt::Now () at /tools/ktorrent/libktorrent-1.1rc1/src/util/functions.cpp:172 #3 0x04c562ca in net::DownloadThread::update (this=0x85069d8) at /tools/ktorrent/libktorrent-1.1rc1/src/net/downloadthread.cpp:53 #4 0x04c56548 in net::NetworkThread::run (this=0x85069d8) at /tools/ktorrent/libktorrent-1.1rc1/src/net/networkthread.cpp:48 #5 0x03ce2e6a in QThreadPrivate::start (arg=0x85069d8) at thread/qthread_unix.cpp:285 #6 0x00cede99 in start_thread (arg=0xaf3aeb70) at pthread_create.c:301 #7 0x00c2cd2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133 Thread 3 (Thread 0xa650ab70 (LWP 14622)): #0 0x00268416 in __kernel_vsyscall () #1 0x00c21c36 in __poll (fds=0xa4b08590, nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0x04c59c46 in net::Poll::poll (this=0x8506df0, timeout=-1) at /tools/ktorrent/libktorrent-1.1rc1/src/net/poll.cpp:99 #3 0x04c55910 in net::UploadThread::waitForSocketsReady (this=0x8506de8) at /tools/ktorrent/libktorrent-1.1rc1/src/net/uploadthread.cpp:129 #4 0x04c55a1f in net::UploadThread::update (this=0x8506de8) at /tools/ktorrent/libktorrent-1.1rc1/src/net/uploadthread.cpp:45 #5 0x04c56548 in net::NetworkThread::run (this=0x8506de8) at /tools/ktorrent/libktorrent-1.1rc1/src/net/networkthread.cpp:48 #6 0x03ce2e6a in QThreadPrivate::start (arg=0x8506de8) at thread/qthread_unix.cpp:285 #7 0x00cede99 in start_thread (arg=0xa650ab70) at pthread_create.c:301 #8 0x00c2cd2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133 Thread 2 (Thread 0xa5d09b70 (LWP 14623)): #0 0x00268416 in __kernel_vsyscall () #1 0x00cf239b in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S:169 #2 0x03ce3567 in wait (this=0xd611bcc, mutex=0xd611bc8, time=4294967295) at thread/qwaitcondition_unix.cpp:88 #3 QWaitCondition::wait (this=0xd611bcc, mutex=0xd611bc8, time=4294967295) at thread/qwaitcondition_unix.cpp:160 #4 0x04c59747 in net::ReverseResolverThread::run (this=0xd611bc0) at /tools/ktorrent/libktorrent-1.1rc1/src/net/reverseresolver.cpp:123 #5 0x03ce2e6a in QThreadPrivate::start (arg=0xd611bc0) at thread/qthread_unix.cpp:285 #6 0x00cede99 in start_thread (arg=0xa5d09b70) at pthread_create.c:301 #7 0x00c2cd2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133 Thread 1 (Thread 0xb7866ab0 (LWP 14389)): [KCrash Handler] #7 0x001b0f2f in _ExtendRange (xkb=0x3f, minKC=0, maxKC=0, changes=0x0) at XKBMAlloc.c:631 #8 XkbChangeKeycodeRange (xkb=0x3f, minKC=0, maxKC=0, changes=0x0) at XKBMAlloc.c:709 #9 0xff800000 in ?? () Reproducible: Always Steps to Reproduce: start ktorrent and wait for crash. Actual Results: segfault Expected Results: no segfault The above backtrace is gathered by Drkonqi who says it's useless. There are addresses in the trace with NO symbols associated with them. Is this the reason? Just before this crash, Kwin goes to 99%+ cpu utilization and the desktop appears to freeze. Xterms AND other X objects refuse to receive(?) input focus at this time. Line 46 of the backtrace contains this "46 #9 0xff800000 in ?? ()", the previous line in the backtrace is "45 #8 XkbChangeKeycodeRange (xkb=0x3f, minKC=0, maxKC=0, changes=0x0) at XKBMAlloc.c:709". Is the trace saying that the code branched into this 0xff800000 address (or tried) and got the segfault or that whatever code at that address incurred a segfault? I think I have all the debuginfo pkgs necessary installed but am not sure since Drkonqi starts the installation in a Konsole which disappears right after the pkg installation (attempt?) ends. I have "ulimit -c unlimited" set but am getting NO corefiles related to this situation. When I logout though, X takes a corefile and logs a backtrace. Are any of these things useful in debuging this problem? The following messages appear closely to the start of ktorrent: No such method kt::App::loadCommandLineOptionsForNewInstance() Warning: QWidget::insertAction: Attempt to insert null action Warning: QWidget::insertAction: Attempt to insert null action Warning: QWidget::insertAction: Attempt to insert null action KCrash: Application 'ktorrent' crashing... KCrash: Attempting to start /usr/libexec/kde4/drkonqi from kdeinit sock_file=/root/.kde/socket-shooter.sleazegate.com/kdeinit4__0
You should don't report open different bugs for the same. This is dup of bug 265794. You should write any addition information in the original bug. Then as I can see reccomendation for you in bug 265794 is to upgrade KTorrent. What version of KTorrent do you use now?
I have closed the other bug, lets continue with this one. Could you run ktorrent under valgrind until it crashes ? valgrind --log-file=vg.log --num-callers=50 /usr/bin/ktorrent --nofork The generated vg.log file, should be very helpful in analyzing the problem. Note that running under valgrind is slow.
Created attachment 57191 [details] targz file containing vg.log and vg.log2
Joris, I ran your valgrind cmd twice. At the end valgrind suggested using "-v" and "--track-origins=yes". vg.log is the original, vg.log2 is with their suggested parameters. George...
[Comment from a bug triager] Just for future references: the reporter suggested that bug 265492 may be related to this
Here is the problem: ==2735== Conditional jump or move depends on uninitialised value(s) ==2735== at 0x4005339: operator delete[](void*, std::nothrow_t const&) (vg_replace_malloc.c:380) ==2735== by 0x5B3CE7: ??? (in /usr/lib/libstdc++.so.6.0.14) ==2735== by 0x5237C8: std::underflow_error::underflow_error(std::string const&) (stdexcept.cc:72) ==2735== by 0x523FAD: virtual thunk to std::strstream::~strstream() (in /usr/lib/libstdc++.so.6.0.14) ==2735== by 0xCF39AD: pthread_once (pthread_once.S:122) ==2735== by 0x5240A8: std::locale::locale() (strstream.cc:369) ==2735== by 0x520F97: std::ios_base::Init::Init() (locale_facets.h:1930) ==2735== by 0x4491935: Strigi::ZipInputStream::checkHeader(char const*, int) (zipinputstream.cpp:36) ==2735== by 0x4493BEC: ??? (in /usr/lib/libstreams.so.0.7.2) ==2735== by 0x4471FCF: ??? (in /usr/lib/libstreams.so.0.7.2) ==2735== by 0xB428FB: call_init (dl-init.c:68) ==2735== by 0xB42A18: _dl_init (dl-init.c:132) ==2735== by 0xB348AE: ??? (in /lib/ld-2.13.so) ==2735== ==2735== Invalid free() / delete / delete[] ==2735== at 0x4005379: operator delete[](void*, std::nothrow_t const&) (vg_replace_malloc.c:380) ==2735== by 0x5B3CE7: ??? (in /usr/lib/libstdc++.so.6.0.14) ==2735== by 0x5237C8: std::underflow_error::underflow_error(std::string const&) (stdexcept.cc:72) ==2735== by 0x523FAD: virtual thunk to std::strstream::~strstream() (in /usr/lib/libstdc++.so.6.0.14) ==2735== by 0xCF39AD: pthread_once (pthread_once.S:122) ==2735== by 0x5240A8: std::locale::locale() (strstream.cc:369) ==2735== by 0x520F97: std::ios_base::Init::Init() (locale_facets.h:1930) ==2735== by 0x4491935: Strigi::ZipInputStream::checkHeader(char const*, int) (zipinputstream.cpp:36) ==2735== by 0x4493BEC: ??? (in /usr/lib/libstreams.so.0.7.2) ==2735== by 0x4471FCF: ??? (in /usr/lib/libstreams.so.0.7.2) ==2735== by 0xB428FB: call_init (dl-init.c:68) ==2735== by 0xB42A18: _dl_init (dl-init.c:132) ==2735== by 0xB348AE: ??? (in /lib/ld-2.13.so) ==2735== Address 0x4dfb24 is not stack'd, malloc'd or (recently) free'd ==2735== So the problem is in strigi's libstreams. What I don't understand is how libstreams is being called from ktorrent.
Joris, Do we need more args for valgrind? I don't care if it goes slower IF it helps solve the problem. Regards, George...
I have created a bug for strigi: https://sourceforge.net/tracker/?func=detail&aid=3179173&group_id=171000&atid=856302 The strigi people should take a look at it.
Joris, Two things here. #1 My other FC14 system does not have these problems with crashes. I'd like to move the .torrent files and their targets to the new system. Can I just copy them to the new system and have that ktorrent use them? #2 I'm not sure if you want a new bug for this problem or not. The %Complete column is not displaying properly I'll attach a jpeg. I think it's related to the previous screen with one check running and 3 waiting for that to finish. Any news from the strigi people? George...
Created attachment 57285 [details] Output of print screen command on partial ktorrent UI window. Output of print screen command on partial ktorrent UI window.
> #1 My other FC14 system does not have these problems with crashes. I'd like to > move the .torrent files and their targets to the new system. Can I just copy > them to the new system and have that ktorrent use them? Yes, if you point ktorrent to the right location, it should work. Can be a big job if you have many torrent. A faster way is to go to ~/.kde/share/apps/ktorrent, in that directory there are a bunch of directories named tor0, tor1, tor2 ... . If you copy those directories to your other computer, it should be OK. But be careful, if tor2 for example already exists on your other computer, then you will have to rename it to torX with X being an unused number. If the data is then copied to the same location on your other computer, then everything is migrated fully. > #2 I'm not sure if you want a new bug for this problem or not. > The %Complete column is not displaying properly I'll attach a jpeg. I think > it's related to the previous screen with one check running and 3 waiting for > that to finish. What widget style are you using ? Most likely this is a problem in the widget style.
Joris, I'm using "system-settings -> application appearance -> style" CDE. I just switched to Motif, no change. Then I switched to several others. CDE and Motif are broken this way... ALL the others are not. I'm willing to make a bug for whoever is responsible for this facility. Can you give me a hint as to who that might be AND how I would describe it's behavior? THANKS! George...
I have no idea under which KDE project this should be reported
[Comment from a bug triager] Both CDE and Motif widget styles are developed and deployed by Qt. http://bugreports.qt.nokia.com/secure/Dashboard.jspa Regards
strigi bug, closing as UPSTREAM
Joris, Have you made a bug report for them or do I need to do this? George...
Yes a bugreport was created for strigi (see one of my posts above)