Open esainane opened 7 years ago
After opening rtorrent, and opening a particular closed torrent to resume a hash recheck ...
Can you describe the steps to reproduce this?
I get this issue constantly on debian 8. I have plenty of free disk space. I have tried with debian deb and building from feature-bind. same result.
0 rtorrent() [0x415374]
1 /lib/x86_64-linux-gnu/libpthread.so.0(+0xf890) [0x7f2878c2a890]
2 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0(+0x7de13) [0x7f2877a11e13]
Error: Success
Signal code '2': Non-existent physical address.
Fault address: 0x7f28740a4000.
The fault address is not part of any chunk.
Aborted
problem still exist. caused by bad sector on disk in my case unfortunately i have already remapped bad sector so can do additional checks.
Description:
After opening rtorrent, and opening a particular closed torrent to resume a hash recheck, rtorrent will crash about 4% through the hash check with SIGBUS.
Terminal output:
GDB trace:
Valgrind log:
Duplicate check:
Going through open and closed issues referencing SIGBUS, I believe this is a new issue:
28 was resolved by setting -O2. When building from source, -O2 was (automatically) used, and the problem persists.
39 has the stack trace finger libtorrent rather than libcrypto, and the probable fix (
a015c336
) has been included in libtorrent for a very long time.90 doesn't describe my issue, rtorrent does not crash immediately.
175 describes an edge case where the disk is too full. I have 55G spare on the destination partition, and 28G spare on the root partition, each of which would be enough several times over.
238 describes an issue with the underlying filesystem. I do not have any relevant warnings or errors in dmesg, and other torrents work correctly.
240 refers to the full disk case.
248 and #356 refer to BTRFS; neither my root nor my destination partitions are BTRFS.
393 refers to the full disk case.
417 may be relevant since libcrypto is fingered in the stack trace, but there isn't enough information in the issue to be sure either way.
526 fingers libtorrent rather than libcrypto.
Reproducibly tested with:
LOG_CONNECTION_FILTER
introduced in the libtorrentfeature-bind
branch, which raises the issue described in #327.Please let me know if there is anything I can do to help.