Version: 3.2 (using KDE 4.2.1) Compiler: gcc version 4.1.2 (Gentoo 4.1.2 p1.1) OS: Linux Installed from: Gentoo Packages When running ktorrent, torrents load and download fine, however after 5 or so minutes my entire desktop locks up for approximately 5 seconds and then ktorrent crashes. I've tried cleaning my .kde4 dir and introducing torrents and plugins one at a time, but have not been able to identify a single cause. This crash occured in KDE 4.2.0 and continues in KDE 4.2.1, I've re-emerged all ktorrent dependencies as well to try and eliminate the crash. After masking the 3.2 version, 3.1.2 has a similar crash. Program received signal SIGBUS, Bus error. [Switching to Thread 0x7f5d89946760 (LWP 1041)] ---Type <return> to continue, or q <return> to quit--- 0x000000344c47aceb in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x000000344c47aceb in memcpy () from /lib/libc.so.6 #1 0x00007f5d8c185218 in ?? () from /usr/lib64/libbtcore.so.9 #2 0x00007f5d8c18b0e0 in bt::Downloader::pieceReceived () from /usr/lib64/libbtcore.so.9 #3 0x00007f5d8c17549c in ?? () from /usr/lib64/libbtcore.so.9 #4 0x00007f5d8c17e2e3 in ?? () from /usr/lib64/libbtcore.so.9 #5 0x00007f5d8c174f24 in ?? () from /usr/lib64/libbtcore.so.9 #6 0x00007f5d8c179475 in bt::PeerManager::update () from /usr/lib64/libbtcore.so.9 #7 0x00007f5d8c1ac999 in bt::TorrentControl::update () from /usr/lib64/libbtcore.so.9 #8 0x000000000042ba26 in ?? () #9 0x0000000000431f5d in ?? () #10 0x00000031b6322998 in QMetaObject::activate () from /usr/lib64/qt4/libQtCore.so.4 #11 0x00000031b631e4fc in QObject::event () from /usr/lib64/qt4/libQtCore.so.4 #12 0x00000031b798a110 in QApplicationPrivate::notify_helper () from /usr/lib64/qt4/libQtGui.so.4 #13 0x00000031b7991080 in QApplication::notify () from /usr/lib64/qt4/libQtGui.so.4 #14 0x00007f5d8b38de12 in KApplication::notify () from /usr/lib64/libkdeui.so.5 #15 0x00000031b631293f in QCoreApplication::notifyInternal () from /usr/lib64/qt4/libQtCore.so.4 #16 0x00000031b6335050 in ?? () from /usr/lib64/qt4/libQtCore.so.4 #17 0x00000031b6332f7b in ?? () from /usr/lib64/qt4/libQtCore.so.4 #18 0x000000344f0349ef in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #19 0x000000344f03790d in ?? () from /usr/lib/libglib-2.0.so.0 #20 0x000000344f037e57 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #21 0x00000031b6333510 in QEventDispatcherGlib::processEvents () from /usr/lib64/qt4/libQtCore.so.4 #22 0x00000031b79f992c in ?? () from /usr/lib64/qt4/libQtGui.so.4 #23 0x00000031b6311efb in QEventLoop::processEvents () from /usr/lib64/qt4/libQtCore.so.4 #24 0x00000031b6312058 in QEventLoop::exec () from /usr/lib64/qt4/libQtCore.so.4 #25 0x00000031b6313b7c in QCoreApplication::exec () ---Type <return> to continue, or q <return> to quit--- from /usr/lib64/qt4/libQtCore.so.4 #26 0x0000000000424742 in _start ()
Any idea what is causing this freeze ? A SIGBUS on memory mapped files (which we use for writing the data to disk), is the result of writing to some part which is not part of the file (beyond the end of the file, for example). This can be caused by another application truncating the file. So maybe something else is messing with the files.
There are only three possibilities that I can think of: 1. Mozilla Firefox - The Download directory of both are set to the same directory, however this happens whether Firefox is running in the background or not. Also, they shouldn't be touching the same files. 2. Amarok - I know it has an autoscan feature, but the directory it autoscans isn't related to the Downloads directory. 3. Nepomuk - I'm not too familiar with how this application works, my assumption is that it is read-only but this may be accessing the files in an improper way? I can't really think of any other applications that would touch the Download directory. Any suggestions on how I can track it down?
Try disabling the strigi indexer of nepomuk (system settings -> advanced -> desktop search) I will run some tests myself with strigi enabled, if it is causing it, I should be able to reproduce it.
Unfortunately the same SIGBUS crash occurs. I ran "inotifywatch -r" on the Download directory and the only accessed directories were the active ones being downloaded until the crash. The reserve disk space option is turned on, and the files all appear to be the correct size.
*** Bug 189067 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > *** Bug 189067 has been marked as a duplicate of this bug. *** In my case it crashes probably because of the ill hard disk on which the data was stored: Apr 7 20:51:40 kagu kernel: [ 1639.647236] sd 2:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK Apr 7 20:51:40 kagu kernel: [ 1639.647244] sd 2:0:0:0: [sdb] Sense Key : Medium Error [current] Apr 7 20:51:40 kagu kernel: [ 1639.647248] sd 2:0:0:0: [sdb] Add. Sense: Unrecovered read error Apr 7 20:51:40 kagu kernel: [ 1639.647253] end_request: I/O error, dev sdb, sector 217374807 In that case ktorrent should output some meaningful error message instead of passing away. Otherwise ktorrent is a really nice app. Good work!
After upgrading to 3.2.1 I have not seen this crash. It used to happen consistently with 3.2. Hopefully it was fixed and nothing like my settings, configurations or lib versions changed.
OK, then, I will close it for now, reopen if you see it again with 3.2.1.
*** Bug 193067 has been marked as a duplicate of this bug. ***