Bug 474498
| Summary: | rtorrent caught sigbus during checksum on x86_64 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Scott Tsai <scottt.tw> |
| Component: | rtorrent | Assignee: | Conrad Meyer <cse.cem+redhatbugz> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 10 | CC: | cse.cem+redhatbugz |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-12-06 03:40:18 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Is this a packaging problem? Or would you be kind enough to file it upstream, and reference the external bug from this one? Do you still get this problem in 0.8.4? Either way this bug should be filed upstream, not against Fedora. I switched to using transmission for that particular torrent before yum picked up the rtorrent-0.8.4 update. |
Description of problem: When trying to resume a torrent. rtorrent outputs: Caught Bus error, dumping stack:0/ 0.0 KB] [Port: 6909] [U 0/0] [D 0/0] [H 0/32] [S 0/1/768] [F 128/128] 0 rtorrent [0x4229fd] 1 rtorrent [0x42553c] 2 /lib64/libc.so.6 [0x320d032f60] 3 /lib64/libcrypto.so.7(sha1_block_data_order+0x5c) [0x3218a64cfc] 4 /lib64/libcrypto.so.7(SHA1_Update+0x1ce) [0x3218a65efe] 5 /usr/lib64/libtorrent.so.11 [0x355b83e70d] 6 /usr/lib64/libtorrent.so.11 [0x355b83e904] 7 /usr/lib64/libtorrent.so.11 [0x355b83ea12] 8 /usr/lib64/libtorrent.so.11 [0x355b83ec46] 9 /usr/lib64/libtorrent.so.11(_ZN7torrent7performEv+0x86) [0x355b82f240] 10 rtorrent [0x4452be] 11 rtorrent [0x423691] 12 /lib64/libc.so.6(__libc_start_main+0xe6) [0x320d01e546] 13 rtorrent [0x40c5e9] A bus error probably means you ran out of diskspace. Aborted (core dumped)b But the partition storing the download still has plenty of disk space:u [scottt@xpc65 ~]$ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb3 1427700212 1023430120 389774820 73% / Version-Release number of selected component (if applicable): rtorrent-0.8.3-1.fc10.x86_64 libtorrent-0.12.3-1.fc10.x86_64 How reproducible: Seems to happen everytime I try to resume this specific torrent. Steps to Reproduce: 1. rotrrent 2. Press Backspace 3. enter torrent filename Actual results: rtorrent catches sigbus then aborts. Expected results: not crashing. Additional info: stack trace from core dump: (gdb) bt #0 0x000000320d032ed5 in raise () from /lib64/libc.so.6 #1 0x000000320d034a43 in abort () from /lib64/libc.so.6 #2 0x0000000000422a6c in do_panic (signum=7) at main.cc:320 #3 0x000000000042553c in sigc::slot0<void>::operator() () at /usr/include/sigc++-2.0/sigc++/functors/slot.h:440 #4 SignalHandler::caught (signum=<value optimized out>) at signal_handler.cc:82 #5 <signal handler called> #6 sha1_block_data_order (c=0x1ee7848, p=0xc6b7e2fb, num=35096) at sha_locl.h:378 #7 0x0000003218a65efe in SHA1_Update (c=0x1ee7848, data_=<value optimized out>, len=3868160) at ../md32_common.h:491 #8 0x000000355b83e70d in torrent::Sha1::update () at ../utils/sha1.h:95 #9 torrent::HashChunk::perform_part (this=0x1ee7830, itr=<value optimized out>, length=4118876453) at hash_chunk.cc:101 #10 0x000000355b83e904 in torrent::HashChunk::perform (this=0x1ee7830, length=3868160, force=true) at hash_chunk.cc:60 #11 0x000000355b83ea12 in torrent::HashQueueNode::perform () at hash_queue_node.h:66 #12 torrent::HashQueue::check (this=0x1d40570, force=37) at hash_queue.cc:160 #13 0x000000355b83ec46 in torrent::HashQueue::work (this=0xfcd54625) at hash_queue.cc:149 #14 0x000000355b82f240 in rak::function0<void>::operator() () at ../../rak/functional_fun.h:102 #15 rak::priority_item::call () at ../../rak/priority_queue_default.h:62 #16 torrent::perform () at torrent.cc:138 #17 0x00000000004452be in core::PollManagerEPoll::poll (this=0x1d38f70, timeout={m_time = 648300}) at poll_manager_epoll.cc:73 #18 0x0000000000423691 in main (argc=<value optimized out>, argv=0x7fff71a18ac8) at main.cc:276 In sha1_block_data_order (c=0x1ee7848, p=0xc6b7e2fb, num=35096) at sha_locl.h:378, the value of variable p seems suspicious.