| Summary: | ktorrent crashes after SIGBUS | ||
|---|---|---|---|
| Product: | [Applications] ktorrent | Reporter: | Mike Woods <miketigerwoods> |
| Component: | general | Assignee: | Joris Guisson <joris.guisson> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | campos.pauloaleixo, w.richert |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Mike Woods
2009-03-09 05:58:37 UTC
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. *** |