Created attachment 70214 [details] crash report obtained via "killall -11" system: openSUSE 12.1 / x86_64 / 3.1.9-1.4-desktop KDE version: 4.8.2 / openSUSE KDE:/Distro:/Factory (http://download.opensuse.org/repositories/KDE:/Distro:/Factory/openSUSE_12.1/) ktorrent version: 4.2 since upgrade from 4.8.1 -> 4.8.2 ktorrent freezes randomly during download of torrents. recently it freezes during application start, too, with the UI appearing after several minutes. when it's frozen, download stops. in this frozen state, no excessive CPU or RAM use is noticeable. after installing debugsource & debuginfo i tried to debug via gdb, but got the following error: -------------------- Reading symbols from /usr/bin/ktorrent... warning: the debug information found in "/usr/lib/debug//usr/bin/ktorrent.debug" does not match "/usr/bin/ktorrent" (CRC mismatch). -------------------- this made me think that somehow i got mismatched packages on my system, so i un- & re-installed ktorrent & libktorrent4, making sure they come from the same repo (K:D:F). this didn't improve things, and at present ktorrent is completely unusable. (doesn't bother me personally, since there are other torrent clients i can use. ) while ktorrent was frozen during app. start, i killed it via "killall -11 ktorrent," which generated the attached bug report (after installing all the debug symbols the crash reporting tool asked me to). as i said, i can live without ktorrent, but it bothers me that it doesn't work w/o any reason i can figure. ("zypper ve" doesn't find anything to complain about.)
thomas lübking suggested on kde-devel: ------------------- seems it's waiting in a sync dbus call of KProtocolManager, resolving a URL - ie. your dbus server might be busy or spammed or whatever. try whether you can call "qdbus org.kde.kwin" during such hang. if it hangs as well, your session bus has trouble. ------------------- but that's not the case. "qdbus org.kde.kwin" returns immediately, w/o error. after deleting all config files for ktorrent (below ~/.kde4/share/...), the app. now hangs on the welcome greeter. at one time i noticed a notification during an attempted start of ktorrent, saying that a certain URL wasn't available. that notification disappeared before i could really get it, and i haven't seen that again. strange thing is that this was with fresh config. files; it shouldn't have been trying to access any URL, IMO. rkhunter & chkrootkit didn't find anything to complain about on my system.
This is a KDE problem not a ktorrent one, kded isn't responding (maybe you should check if it is running ?). Reassigning it to the right people.
I can confirm this bug, and that it affects more than just ktorrent. It's also tremendously annoying, why does IPC have to be so much of a problem with this major release of KDE? I'll add backtraces as I can, but the common thread I've seen has been a backtrace like: #0 0x00007fbee63643e8 in poll () from /lib64/libc.so.6 #1 0x00007fbedac1ddca in socket_do_iteration () from /usr/lib64/libdbus-1.so.3 #2 0x00007fbedac1c47f in _dbus_transport_do_iteration () from /usr/lib64/libdbus-1.so.3 #3 0x00007fbedac09693 in _dbus_connection_do_iteration_unlocked () from /usr/lib64/libdbus-1.so.3 #4 0x00007fbedac0aeed in _dbus_connection_block_pending_call () from /usr/lib64/libdbus-1.so.3 #5 0x00007fbedac09fcd in dbus_connection_send_with_reply_and_block () from /usr/lib64/libdbus-1.so.3 #6 0x00007fbee7be1e2d in q_dbus_connection_send_with_reply_and_block ( error=0x7fff0bf18a30, timeout_milliseconds=-1, message=0x24a0ec0, connection=0x21908b0) at /kdesvn/src/qt/src/dbus/qdbus_symbols_p.h:135 #7 QDBusConnectionPrivate::sendWithReply (this=0x218c520, message=..., sendMode=<optimized out>, timeout=-1) at /kdesvn/src/qt/src/dbus/qdbusintegrator.cpp:1904 #8 0x00007fbee7bcc95b in QDBusConnection::call (this=0x2b7a928, message=..., mode=<optimized out>, timeout=<optimized out>) at /kdesvn/src/qt/src/dbus/qdbusconnection.cpp:597 #9 0x00007fbee7bf0034 in QDBusAbstractInterface::callWithArgumentList ( this=0x2b6fc58, mode=QDBus::Block, method=..., args=...) at /kdesvn/src/qt/src/dbus/qdbusabstractinterface.cpp:468 So far I've seen it affecting Kontact/Akonadi, Phonon (as used by JuK), the logout dialog and konqueror (or KIO). This bug occurs with kdelibs git-master (perhaps it will be a simple as downgrading kdelibs to 4.8.1 to fix though?). DBus 1.4.18 and 1.4.20 are both affected in my testing. Example error output for Phonon: juk(5599) Phonon::KdePlatformPlugin::createBackend: using backend: "GStreamer" juk(5599)/phonon (KDE plugin): QDBusError("org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.") juk(5599)/phonon (KDE plugin): QDBusError("org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.") juk(5599)/phonon (KDE plugin): QDBusError("org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.") As best I can tell, the DBus session bus remains active and responsive throughout, but calls seemingly randomly hang.
So I seem to be in a KDE session not affected by this issue after some cleaning/sanitization... Some of the debugging I've done to this point is to strace processes that are waiting on a reply from DBus (kontact, klauncher, kded4 especially). There was nothing especially illuminating unfortunately (and was done at a Linux TTY and I forgot to log the strace output). The strace output consisted mostly of poll()/recvmsg() syscalls, where poll() would timeout (once a second) and recvmsg() would give EAGAIN. Looking at the fd that recvmsg() was being called in (under /proc/$PID/fd and /proc/$PID/fdinfo), the recvmsg() was being called on a Unix domain socket, with flags of close-on-exec, read/write, and non-blocking set. So in this case EAGAIN is actually innocuous: It just means that there is nothing to receive (similar to EWOULDBLOCK). Based on reports of this same type of issue (even from years past), and based on the file descriptors open for affected processes according to /proc/$PID/fd, I tried unlinking $KDEHOME/cache-$HOSTNAME/{libphonon/*,ksycoca} while outside of KDE and restarting. That didn't help. However (and I forget what prompted me to look at this, I think I saw permission denied warnings), running the ipcs command to list open SysV IPC primitives showed some semaphores and shared memory segments opened to other users from previous logins. I used ipcrm to remove those stole IPC primitives and *so far* everything has been working properly in this desktop session. If anyone has any clue why SysV IPC would affect some DBus connections (permissions?) I'd be happy to try and reproduce. This is the kind of thing that even if it's an "installation issue" is nearly impossible to debug and so should be identified by the runtime (or better yet, made such that it's not a problem at all).
right; it's starting to happen with amarok now. not interrupting the playback, but freezing the UI. and as somebody suggested earlier, kded4 is running. looking at kded4 processes, i see that i have one running as root. probably because i've started kppp as root and that's running still?
i haven't tried ktorrent in a while, but now it seems to start & work ok. there were several updates to KDE packages in the meantime, so i have no idea which one did it. don't see similar problems with other app.s either.
I can confirm this bug with ktorrent after upgrading to 4.8.2 (fc16), the UI becomes unresponsive. The reload of X makes it run smoothly for some short time, then it freezes again. Any workaround?
I can confirm the same bug with KDE 4.8.3 (fc16).
Is there any progress? On fc17 ktorrent still suffers from the same problem.
Kubuntu 13.04 Qt: 4.8.4 KDE Development Platform: 4.10.4 KTorrent: 4.3.1 KTorrent gui freezing when writing data to disk while downloading if download speed more then 3 MiB/s
Ktorrent freezes when saving to any other drive than your KDE one. When downloading to desktop it's OK, but when downloading to another drive with NTFS or FAT32 filesystem the program crashes......
And the most strange thing - on my laptop everything is OK, but not on my PC ... (In reply to comment #11) > Ktorrent freezes when saving to any other drive than your KDE one. When > downloading to desktop it's OK, but when downloading to another drive with > NTFS or FAT32 filesystem the program crashes......
Is this still happening in Plasma 5.19 or a similarly recent version?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!