Description of problem: rtorrent starts up fine, but once it's downloaded the entire target file, it segfaults instead of continuing to upload back to the torrent. Version-Release number of selected component (if applicable): rtorrent-0.5.3-1.fc5 How reproducible: Start a torrent download and let it complete. Steps to Reproduce: 1. rtorrent http://torrent.fedoraproject.org/torrents/fc6-test2-dvd- x86_64.torrent 2. wait until the file has completely downloaded 3. see rtorrent segfault Actual results: segfault: Caught Segmentation fault, dumping stack:B] [Port: 6920] [U 0/15] [S 0/1/ 768] [F 2/128] 0 rtorrent [0x80574a1] 1 rtorrent [0x8069416] 2 [0x608420] 3 rtorrent [0x80a8230] 4 rtorrent [0x8097bec] 5 rtorrent [0x805905a] 6 /lib/libc.so.6(__libc_start_main+0xdc) [0x63b724] 7 rtorrent(_ZN7torrent18set_max_open_filesEj+0x95) [0x8050fb1] Expected results: rtorrent should continue to upload to the torrent.
I'll try to reproduce the problem here locally, in the meantime could you please install rtorrent-debuginfo, and try again? The resulting segfault should have a bit more of a clue to follow up on then Thanks in advance!
Just installing the debuginfo didn't seem to get me anything else, but I installed the debuginfo and ran it under gdb and got: Program received signal SIGSEGV, Segmentation fault. core::CurlStack::perform (this=0x84720f8) at curl_stack.cc:82 82 rak::equal(msg- >easy_handle, std::mem_fun(&CurlGet::handle))); (gdb) where #0 core::CurlStack::perform (this=0x84720f8) at curl_stack.cc:82 #1 0x08097bec in core::PollManagerEPoll::poll (this=0x84720f0, timeout= {m_time = 424510}) at poll_manager_epoll.cc:92 #2 0x0805905a in main (argc=2, argv=0xbff6d424) at main.cc:254 #3 0x0063b724 in __libc_start_main () from /lib/libc.so.6 #4 0x08050fb1 in _start () I still have the gdb session sitting there if you want me to try and gather any further info from it.
I noticed that segfault immediately when hash check operation finishes after download is complete and rtorrent continues to upload. Very simualar to that described here: http://libtorrent.rakshasa.no/ticket/324 The strace looks somehow different then yours, Kevin. Maybe you hit something unrelated to that. Chris, please could you consider to build a new package from the recommended 'unstable release' ?
I would be happy to test a newer version here and see if the problem persists. It always happens after the download finishes, so it might be the same issue...
(In reply to comment #4) > I would be happy to test a newer version here and see if the problem persists. +1 > It always happens after the download finishes, so it might be the same issue... Not immediately after the download finishes, but when the hash check reaches 100 percent. There is an option in .rtorrent.rc(check_hash = no) which seems to disable this operation, but that is commented out. I just uncommented it and started a new file transfer. Meanwhile I also found a newer version in the fc-devel-extras repo. I will try to rebuild the SRPM for fc5 over the weekend and will report success/failure here.
Looking @ the changelogs of rtorrent and libtorrent it would seem these have been fixed upstream, i'll push the new versions (rtorrent 0.6.2 and libtorrent 0.10.2) over the weekend to fc5 and devel. If the problem still persists after this (i'll check up on it too) i'll try to work with the upstream maintainer to get it fixed
libtorrent 0.10.2 and rtorrent 0.6.2 have been pushed and build for the fc4, fc5 and devel branches.. Reportedly this should fix the described errors. Packages should hit the extra's repos 'any time soon' (as soon as their signed)
No feedback from the original reporter(s) yet, however the recently pushed updates fixed the problem here locally .. so closing the bug for now. Please re-open if the problem pertains
rTorrent 0.6.2 - libTorrent 0.10.2 is running fine...Thanks.
I can confirm that it's working fine here too. Thanks for the fix. :)