rtorrent segfault on d.erase command

[bert@biot.com]

This was done with a recent (~ 2 days ago) snapshot from the svn trunk of rtorrent. The ~/.rtorrent.rc had something like this:

system.method.set_key = event.download.finished,kill_when_done,"d.stop= ;d.close= ;execute=mv,$d.get_base_path=,/data/torrent ;d.erase="

The execute command is done, i.e. the files are moved to /data/torrent, but when running the d.erase command rtorrent segfaults:

(gdb) bt full
#0  0xb7de9feb in torrent::Download::is_active (this=0x8156af0) at download.cc:189
No locals.
#1  0x080ba8b8 in core::DownloadList::hash_done (this=0x8156af0, download=0xbfd5be04)
    at download_list.cc:470
        hashing = <value optimized out>
#2  0x080bbece in sigc::internal::slot_call0<sigc::bind_functor<-1, sigc::bound_mem_functor1<void, core::DownloadList, core::Download*>, core::Download*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>, void>::call_it (rep=0x81c43d8) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1851
No locals.
#3  0xb7e432e2 in torrent::DownloadWrapper::receive_initial_hash (this=0x81f2010)
    at /usr/include/sigc++-2.0/sigc++/signal.h:550
No locals.
#4  0xb7e4500b in rak::mem_fn0_t<torrent::DownloadWrapper, void>::operator() (this=0x81c1878)
    at ../../rak/functional_fun.h:229
No locals.
#5  0xb7dfbd95 in torrent::perform () at ../../rak/functional_fun.h:102
No locals.
#6  0x080ca316 in core::PollManagerEPoll::poll (this=0x815dee8, timeout={m_time = 673296})
    at poll_manager_epoll.cc:73
No locals.
#7  0x08083c96 in main (argc=1, argv=0xbfd5c274) at main.cc:279
        firstArg = <value optimized out>
(gdb)

According to Josef, this means the torrent is still getting events after it's been erased, which shouldn't happen.

[Prittyimmax]

 http://forum.37signals.com/basecamp/users/17324 pornhub loan

[dbrobins (AT) i4031.net]

I fixed this locally by modifying core::DownloadList::confirm_finished to fetch the info hash before dispatching the "finished" event and then only manipulating the download object further if the hash is still found (similar to what is done in DownloadFactory::receive_success). Patch attached.

[veltzerdoron@gmail.com]

I tried your patch and got the exception

rtorrent: View::filter_download(...) could not find download.

for my troubles

I'm using the latest source ( rtorrent-0.8.5 and libtorrent-0.12.5)

I am not a simple leech, I'm currently running statistical tests on rTorrent and want to restart torrents once they are finished so that this can happen automatically(I also have a script that restores the torrent file after it is erased to do this) I've been trying to do this for about a month now but cannot proceed without the d.erase= working properly.

any ideas when a full patch will be introduced for this or how my problem can be fixed? I would really prefer not to go into the rtorrent viewer source and hack it.

[rakshasa]

That's not the latest source...

[anonymous]

Replying to rakshasa:

That's not the latest source...

Well it was 5 months ago, so the patch was done with the latest source, huh? I will try to update (though it is quite a pain) and see how goes.

[anonymous]

Replying to anonymous:

Replying to rakshasa:

That's not the latest source...

Well it was 5 months ago, so the patch was done with the latest source, huh? I will try to update (though it is quite a pain) and see how goes.

The lines in the patch now dont match the ones in the file, should I insert the patch or has the problem been solved in the proper way in the release itself?

[anonymous]

Tried both versions with and without the patch got this thrown message

rtorrent: View::filter_download(...) could not find download.

any patch for this coming our way? I'd really rather not try to patch it myself as this would entail a big hassle.

Replying to anonymous:

Replying to anonymous:

Replying to rakshasa:

That's not the latest source...

Well it was 5 months ago, so the patch was done with the latest source, huh? I will try to update (though it is quite a pain) and see how goes.

The lines in the patch now dont match the ones in the file, should I insert the patch or has the problem been solved in the proper way in the release itself?

[anonymous]

this is the only event I have setup

system.method.set_key = event.download.finished,remove_torrent,"d.erase="

and it crashes the same on all version with or without the patch please, aidez moi.

[anonymous]

If anyone can attach an rTorrent.rar source code version that can delete torrents on completion (.rtorret.rc file included) I will consider naming my next child after them (only consider because rakshasa is a heavy load to carry).

[veltzerdoron@gmail.com]

The only way I could overcome this bug was running rtorrent in an external script loop and adding some torrent management scripts (backup and restore, session removal, that sort of thing). I find this solution repulsive, also had to disable hash checking on load which caused the restart process to take forever, which I didn't like doing.

I also would rather not try and fix this myself as I found the event handling code rather difficult at first glance, Do you think there will be a fix for this?

[JSturgesJr@gmail.com]

Ok. this can be fixed in two ways

1. by using the schedule= instead of the execute command to erase torrents after a period of time that allows the torrent to finish his business before removing the torrent session and all:

system.method.set_key = event.download.finished,remove_torrent,"schedule=remove_torrent_delayed,3,0,d.erase="

2. by scheduling a remove_untied event once every 10 secs instead of the regular stop_untied, and deleting the torrent file on finished:

system.method.set_key = event.download.finished,remove_torrent,"execute_nothrow=rm,-rfv,$d.get_tied_to_file="
#and
schedule = untied_directory,15,15,remove_untied=

The second method is less recommended since I read (though haven't tested this myself) that it causes problems with the tracker (the stats on the tracker are hurt somehow).

Enjoy

[anonymous]

Replying to JSturgesJr@…:

Ok. this can be fixed in two ways 1. by using the schedule= instead of the execute command to erase torrents after a period of time that allows the torrent to finish his business before removing the torrent session and all:

That method breaks if two torrents finish within 3 seconds of each other, the second one will overwrite the schedule of the first.

A better way is to add finished torrents to a custom view, and regularly run a d.multicall on that view. I'm afraid I don't have working code for this however but it shouldn't be too hard to do.

To always wait at least x seconds before removal, use a branch in the schedule to set a d.custom if it's not set, and to otherwise remove the download if it's set. Then run the schedule every x seconds.

[sirjaren <sirjaren@gmail.com>]

The above patch is a revision of dbrobin's prior patch.

It replaces the old download->info_hash goodness with info->hash.

It also works with SVN (r1164) at the time of this patch.

Let me know if it works, as it works for me currently.

[rakshasa]

Committed.

[anonymous]

I'm not sure this is a complete fix, it still seems broken in r1170, only now I get "rtorrent: View::filter_download(...) could not find download." instead of a segfault.

[sirjaren <sirjaren@gmail.com>]

That is because you are using the wrong patch. Use rtorrent-9999-finished[1].patch instead as the old patch uses download->info_hash instead of info->hash.

[sirjaren <sirjaren@gmail.com>]

Disregard my last message, if you are using TRUNK, that issue may be entirely different from this. I'll test, but I'm not having this issue. Are you using d.erase via xmprpc or sending the command on an event (or manually) through rtorrent?

[anonymous]

system.method.set_key = event.download.finished,move_complete,"execute=mv,-u,$d.get_base_path=,~/torrents/complete/ ;d.set_directory=~/torrents/complete/; d.ignore_commands.set=1; d.close=; d.erase="

I've tried various combinations (without ignore_commands, with and without stopping/closing) on the off chance I was chaining together things I shouldn't have, but everything exits the same way.

My configuration is otherwise very plain, so I'm not sure what else I might be doing that you aren't.

[jonson]

7R7Mu9  http://cra3Zzphu47hvm4bbmp82f0vwJs.com