Ticket #955 (new brain_dump)

Get the Azureus people to document their magnet protocol and this might be worth considering.

As said.

Magnet URIs are hash-based identifiers (See  http://en.wikipedia.org/wiki/Magnet_link for details) so I suspect that Azureus' Magnet support is somehow dependant on it's DHT support... something rTorrent doesn't have yet.

I've written a patch to support magnet links now. You need to check out svn rev 1065 of libtorrent/rtorrent, and get  http://ovh.ttdpatch.net/~jdrexler/rt/experimental/dht-pex-static_map.diff and  http://ovh.ttdpatch.net/~jdrexler/rt/experimental/magnet-uri.diff then in the directory that has the libtorrent and rtorrent subdirs you've checked out, do

patch -p0 < dht-pex-static_map.diff
patch -p0 < magnet-uri.diff

and recompile both.

It uses the official magnet protocol from Bittorrent BEP-0009 which is incompatible with Azureus and so far only supported by uTorrent 1.8+, so it'll only work if there are recent uTorrents in the swarm. It supports magnet links in both the old style base32 encoded hashes as well as the recommended URL-encoded hashes.

Note that if there is one or more tracker URLs to use for the download, it must be present as "tr=..." argument in the magnet URI, because there is currently no way of adding trackers in rtorrent afterwards, so without that it'll use DHT and nothing else.

After opening a magnet URI, it will add a meta download to download the actual torrent info. When that is complete, it is replaced by the real torrent. The meta data is saved in your standard torrent download directory, you can delete that after the real torrent has appeared, or you can keep it in case you need to open the same magnet URI again.

I've updated the above patches for r1087/0.8.4. There's also a new feature that allows you to load magnet links using a normal watch directory, so that you can e.g. click on a magnet link in your browser and have rtorrent load it without even needing xmlrpc.

Basically, set your browser to call a bash script like this (requires bash 3.x), with the magnet URI as argument:

#!/bin/bash

cd ~/watch    # set your watch directory here
[[ "$1" =~ xt=urn:btih:([^&/]+) ]] || exit;
echo "d10:magnet-uri${#1}:${1}e" > "meta-${BASH_REMATCH[1]}.torrent"

(Putting magnet URIs in torrent files like this is non-standard, but the files wouldn't be distributed anyway so this shouldn't hurt. Other torrent clients wouldn't accept the file and treat it like an empty file.)

Another feature is that the temporary *.meta files are tied to the (real) download, so that when it completes they will be deleted with the usual delete_tied commands. If you want to keep the *.meta file for a download, make a copy or untie it first (if you use delete_tied).

Since TPB is moving away from torrent files and instead promoting magnet links, is there any chance that we can get this feature added any sooner? It's going to be more and more relevent, I think

I was about to ask the same since I read  http://torrentfreak.com/the-pirate-bay-tracker-shuts-down-for-good-091117/ based on  http://thepiratebay.org/blog (Worlds most resiliant tracking)

I can't get this working. I checked out r1093 (since the patches seem to be against that version now), and applied the patches and set magnet handler to that script in firefox. rtorrent seems to completely ignore the meta*.torrent file, nothing appears in the log and nothing is downloaded.

The magnet URIs I tried were from The Piratebay, since they now have them for all torrents. For example, a magnet link for Mint Linux:

magnet:?xt=urn:btih:e6d127825ea38b231ce59eac0d15ddd66ee46284&dn=Linux+Mint+7+Gloria+-+Main+Edition

That script creates a file named meta-e6d127825ea38b231ce59eac0d15ddd66ee46284.torrent with the content

d10:magnet-uri98:magnet:?xt=urn:btih:e6d127825ea38b231ce59eac0d15ddd66ee46284&dn=Linux+Mint+7+Gloria+-+Main+Editione

Unfortunately Piratebay's magnet uris are this hex hash type, so they don't work directly in Vuze either...

This doesn't follow any accepted encoding scheme. Although the encoding is obvious, nobody else does it that way.

You can just take the plain-text infohash from the link (which should've been EITHER base32-encoded OR url-encoded but NOT hex-encoded as it is here), and plug it into a magnet link generator. For instance, for your link you would get magnet:?xt=urn:btih:43ISPAS6UOFSGHHFT2WA2FO52ZXOIYUE which seems to work.

Please have a look at the specification, which can be found here:

 http://www.bittorrent.org/beps/bep_0009.html#magnet-uri-format

that we can oppose to this one, alas:  http://www.azureuswiki.com/index.php/Magnet_link

or I could just support everything and the kitchen sink

apply this after the other magnet patches to get hex-encoded hash support:  http://ovh.ttdpatch.net/~jdrexler/rt/experimental/magnet-hex-hash.diff

Given the fact that The Pirate Bay is one of the worlds largest torrent sites, and a fair portion of all rtorrent users are impacted by their move to magnet links, will there be an official rtorrent release supporting HEX-encoded magnet links?

Yeah could somebody review the patches - somebody who's C is better than mine - and apply them to mainline trunk? Following BEP 0009 is a good thing and the only thing we should do in rtorrent. The watch dir hack seems a little bit evil. I would prefer a xmlrpc approach? You could simply call it over curl or whatever. And to be super clean I wouldn't apply the base32 patch and just do this in the bash script. I couldnt test the patch myself (just briefly looked through the code) because I'm on a crappy 3G connection right now. NAT + slow = evil combination.

I guess it's soon about time I take a look at this. ^_

Replying to rakshasa:

I guess it's soon about time I take a look at this. ^_

Oh nice to see you guys working on this, i've been trying the last 2 days to get these patches in myself, pain in the ass :)

Replying to josef:

or I could just support everything and the kitchen sink apply this after the other magnet patches to get hex-encoded hash support:  http://ovh.ttdpatch.net/~jdrexler/rt/experimental/magnet-hex-hash.diff

Works for me and pretty fast too! Both the patch and finding the downloads that is. Well, except if rtorrent doesn't find the download, then it just quits the entire program. Not very userfriendly. A zero-length *.meta file remains behind too.

Replying to iNPUTmice:

Yeah could somebody review the patches - somebody who's C is better than mine - and apply them to mainline trunk? Following BEP 0009 is a good thing and the only thing we should do in rtorrent. The watch dir hack seems a little bit evil. I would prefer a xmlrpc approach? You could simply call it over curl or whatever. And to be super clean I wouldn't apply the base32 patch and just do this in the bash script. I couldnt test the patch myself (just briefly looked through the code) because I'm on a crappy 3G connection right now. NAT + slow = evil combination.

Better to be compatible than 'super clean'

 http://bittorrent.org/beps/bep_0009.html#magnet-uri-format

"For compatability with existing links in the wild, clients should also support the 32 character base32 encoded info-hash."

Replying to anonymous:

Works for me and pretty fast too! Both the patch and finding the downloads that is. Well, except if rtorrent doesn't find the download, then it just quits the entire program. Not very userfriendly. A zero-length *.meta file remains behind too.

That's clearly a bug. Please post the output (if there is any), or run it in gdb and post the output of "backtrace full" when it crashes.

What exactly do you do to make it crash, and what do you mean by "find the download"?

Replying to josef:

That's clearly a bug. Please post the output (if there is any), or run it in gdb and post the output of "backtrace full" when it crashes. What exactly do you do to make it crash, and what do you mean by "find the download"?

I just clicked on a magnet link in Firefox to make it quit after rtorrent tries to start the download, it doesn't really look like a crash.

"Find the download" was the message from rtorrent:

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

This seems to be as in "unable to find a peer with the data for this torrent" or "unable to proceed from meta*.torrent to hash.meta file" and hence the empty *.meta file. The magnet link in question is

magnet:?xt=urn:btih:7fc9986bb4eee10a5f718031bcc603996e651d7cdn=Psych.S04E07.High.Top.Fade.Out.HDTV.XviD-FQM.avi&tr=http%3A%2F%2Ftracker.prq.to%2Fannounce

On the third time that I tried this link just now, the download just started. Removed the torrent and files and started again, and now it again aborted. This is the little output I get in gdb:

(gdb) run
Starting program: /usr/local/bin/rtorrent 
[Thread debugging using libthread_db enabled]
rtorrent: View::filter_download(...) could not find download.

Program exited with code 0377.
(gdb) backtrace full
No stack.
(gdb) 

I also got just "Program exited normally" on a previous run from gdb.

This seems to be an issue with a filter option you've set. I can't reproduce the crash here. I guess it's something that's run after the meta download is removed but before the real download is re-added.

Hi, I recently compiled and installed rTorrent 0.8.5/0.12.5. Are patches above applicable or do I have to use svn 1065 (I do not know how to do that (hmm, and a short answer is enough, better to focus upon getting the stuff in an ordinary release))?

And, by the way, thank you for a splendid client!

Whats the status of this in the trunk ?

/T

Replying to josef:

This seems to be an issue with a filter option you've set. I can't reproduce the crash here. I guess it's something that's run after the meta download is removed but before the real download is re-added.

Its probably this filter that destroys stuff: schedule = untied_directory,10,180,stop_untied=

/T

Replying to anonymous:

Replying to josef:

This seems to be an issue with a filter option you've set. I can't reproduce the crash here. I guess it's something that's run after the meta download is removed but before the real download is re-added.

Its probably this filter that destroys stuff: schedule = untied_directory,10,180,stop_untied=

Well, the same thing still happened even with the default rtorrent.rc (i.e. trunk/rtorrent/doc/rtorrent.rc), I only changed port_range and dht_port to match my firewall. The schedule=untied_directory... stuff is commented out in there so I don't think that's the problem. But doesn't look like it's something I have set.

Replying to anonymous:

Replying to anonymous:

Replying to josef:

This seems to be an issue with a filter option you've set. I can't reproduce the crash here. I guess it's something that's run after the meta download is removed but before the real download is re-added.

Its probably this filter that destroys stuff: schedule = untied_directory,10,180,stop_untied=

Well, the same thing still happened even with the default rtorrent.rc (i.e. trunk/rtorrent/doc/rtorrent.rc), I only changed port_range and dht_port to match my firewall. The schedule=untied_directory... stuff is commented out in there so I don't think that's the problem. But doesn't look like it's something I have set.

I am having a same issue. With "could not fild download" and same output from gdb.

A meta file was created before it exited. And if I load same magnet link one more time with metafile in download directory then it worked. If I removed a metafile before second load, it created a new metafile and exited.

Also on a first try, name of a file that was displayed in a main view was a name of metafile. Then on a second try, correct file name was displayed and start downloading.

I should note that I'm testing this on a Ubuntu 9.10 64bit with gcc-4.3.3 and I added "#include <cstdio>" in dht_server.cc and download_constructor.cc to compile. Also I made changes noted in ticket#1761 to xmlrpc.cc.

I should note that I'm testing this on a Ubuntu 9.10 64bit with gcc-4.3.3 and I added "#include <cstdio>" in dht_server.cc and download_constructor.cc to compile. Also I made changes noted in ticket#1761 to xmlrpc.cc.

gcc-version was incorrect. It is gcc-4.4.1.

I have compiled rtorrent/libtorrent from svn repository (release 1093) and applied the following patches: - dht-pex-static_map.diff, - magnet-uri.diff, - magnet-hex-hash.diff. But I can't for the life of me not figure out how to input the magnet link to rtorrent. Can I paste the magnet URI in a text file in the watch directory?

After (succesfully) applying the patches to the FreeBSD ports rtorrent fails to configure on xmlrpc-c-config with these errors:

/usr/local/lib/libtorrent.so: undefined reference to `vtable for torrent::PeerConnectionMetadata'
/usr/local/lib/libtorrent.so: undefined reference to `torrent::StaticMapKeys::StaticMapKeys(torrent::StaticMapKeys::mapping_type const*, unsigned int)'

(FreeBSD 6.4, i386, GCC 4.2.5)

Replying to Jimmy:

I have compiled rtorrent/libtorrent from svn repository (release 1093) and applied the following patches: - dht-pex-static_map.diff, - magnet-uri.diff, - magnet-hex-hash.diff. But I can't for the life of me not figure out how to input the magnet link to rtorrent. Can I paste the magnet URI in a text file in the watch directory?

Just compy the link press <enter> and paste the link then <enter> again and voila you are done.

/T

Replying to anonymous:

Replying to anonymous:

Replying to josef:

This seems to be an issue with a filter option you've set. I can't reproduce the crash here. I guess it's something that's run after the meta download is removed but before the real download is re-added.

Its probably this filter that destroys stuff: schedule = untied_directory,10,180,stop_untied=

Well, the same thing still happened even with the default rtorrent.rc (i.e. trunk/rtorrent/doc/rtorrent.rc), I only changed port_range and dht_port to match my firewall. The schedule=untied_directory... stuff is commented out in there so I don't think that's the problem. But doesn't look like it's something I have set.

Cant someone with the rtorrent trunk that have not applied the magnet patches just test adding the schedule=untied_directory... stuff and see if its crashes when adding a normal .torrent file.

/T

Replying to Oliver:

{{{ /usr/local/lib/libtorrent.so: undefined reference to `vtable for torrent::PeerConnectionMetadata?' /usr/local/lib/libtorrent.so: undefined reference to `torrent::StaticMapKeys::StaticMapKeys?(torrent::StaticMapKeys::mapping_type const*, unsigned int)' }}} (FreeBSD 6.4, i386, GCC 4.2.5)

Did you recompile and install libtorrent first? The patches apply to it as well.

If you did, try running the libtorrent autogen.sh first. Then configure, make and install libtorrent. Also make sure there are no old headers or library versions on your system.

I'm afraid I can't make it crash like that no matter what I try, regardless of whether I add that stop_untied= command or not, or whether I add the download by pressing <return>, <backspace>, as a meta torrent file or via xmlrpc.

Sorry, I can't fix this if I can't reproduce it. I have upgraded to svn revision 1100 since applying the patches however. Are you still running rev 1093? Or did you upgrade to a newer version than that?

I have applied all 3 mentioned patches on latest SVN

dht-pex-static_map.diff magnet-hex-hash.diff magnet-uri.diff

But when I try to compile libtorrent it gives me this error.

Without patches compilation and install works without problems.

dht_server.cc: In member function âvirtual void torrent::DhtServer::event_read()â: dht_server.cc:762: error: âsnprintfâ was not declared in this scope make[3]: *** [dht_server.lo] Error 1 make[3]: Leaving directory `/home/erol/rtorrent/trunk/libtorrent/src/dht' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/erol/rtorrent/trunk/libtorrent/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/erol/rtorrent/trunk/libtorrent' make: *** [all] Error 2

Replying to anonymous:

Replying to Oliver:

undefined references (FreeBSD 6.4, i386, GCC 4.2.5)

Did you recompile and install libtorrent first? The patches apply to it as well. If you did, try running the libtorrent autogen.sh first. Then configure, make and install libtorrent. Also make sure there are no old headers or library versions on your system.

Running autogen.sh first solved it. Still fumbling around with the bash-script, but when i use the magnet command inside rtorrent itself I get the View::filter_download(...) could not find download. clean exit thingy. I used

magnet:?xt=urn:btih:43ISPAS6UOFSGHHFT2WA2FO52ZXOIYUE

for the LinuxMint? iso mentioned earlier

First time I gave the command the main view showed E6D127825EA38B231CE59EAC0D15DDD66EE46284.meta. I can see it go round searching nodes, then announcing and just when it starts donwloading the exit happens. a file E6D127825EA38B231CE59EAC0D15DDD66EE46284.meta remains in my downloaddir with 27994 bytes of data in it.

Second time round, same command, main view now shows the correct LinuxMint?-7.iso name and after searching and announcing the thing started leeching. Another round of searching (I missed announcing, but I take it that too) after completion, now I'm seeding.

Downloaddir now contains the iso AND the hex.meta remnant.

hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

Sorry, all I can say is that it works for me. I add the download via the magnet link, it searches nodes and announces, replaces the meta download with the real one and starts downloading. No crash, no other problems.

There must be something subtly different on FreeBSD that causes things to behave differently there. It works for me on both Linux and OS X anyway. I'm afraid I can't help you.

That's OK, I'm in no hurry, just hope someone keeps an eye on it when it makes it way upstream.

One question remains though if it's not too much to ask. Can anyone point me to directions on how to convert the 40 byte hex codes to 32 byte base32-codes, preferably in PHP? I found an example on the PHP website (in a comment) but that didn't work.

I can do it in Perl. Should be easy to translate if you can find a base32-encode function in PHP.

#!/usr/bin/perl -l

use MIME::Base32 qw(RFC);

$_ = shift;
die "$_ is not an SHA1 hash\n" if length != 40 or /[^A-F0-9]/i;
s/([A-F0-9]{2})/chr hex $1/egi;
print "magnet:?xt=urn:btih:", MIME::Base32::encode($_), map "&tr=$_", @ARGV;

It takes a hex-encoded SHA1 as first argument and spits out the corresponding base32 magnet link. Additional arguments are used as tracker URLs.

Replying to karven2:

Hi, I recently compiled and installed rTorrent 0.8.5/0.12.5. Are patches above applicable or do I have to use svn 1065

I've just applied the patches and recompiled to the latest SVN version and all seems to be working just fine.

Thanks for all the work

So when is this getting into trunk and hence into distribution packages like debian's?

Replying to anonymous:

Replying to anonymous:

Replying to anonymous:

Replying to josef:

This seems to be an issue with a filter option you've set. I can't reproduce the crash here. I guess it's something that's run after the meta download is removed but before the real download is re-added.

Its probably this filter that destroys stuff: schedule = untied_directory,10,180,stop_untied=

Well, the same thing still happened even with the default rtorrent.rc (i.e. trunk/rtorrent/doc/rtorrent.rc), I only changed port_range and dht_port to match my firewall. The schedule=untied_directory... stuff is commented out in there so I don't think that's the problem. But doesn't look like it's something I have set.

I am having a same issue. With "could not fild download" and same output from gdb. A meta file was created before it exited. And if I load same magnet link one more time with metafile in download directory then it worked. If I removed a metafile before second load, it created a new metafile and exited. Also on a first try, name of a file that was displayed in a main view was a name of metafile. Then on a second try, correct file name was displayed and start downloading. I should note that I'm testing this on a Ubuntu 9.10 64bit with gcc-4.3.3 and I added "#include <cstdio>" in dht_server.cc and download_constructor.cc to compile. Also I made changes noted in ticket#1761 to xmlrpc.cc.

Same issue here (Debian unstable): latest svn, only the three patches applied, rtorrent segaults when the magnet link is started.

If it segfaults, please run it in gdb and post the output of "backtrace full". The former crashes weren't segfaults, just terminating because of an assert (or similar).

I'm successfuly patched r1104 (dht-pex-static_map.diff, magnet-hex-hash.diff, magnet-uri.diff). When i adding any magnet link and press Ctrl+S, rtorrent waits some time, and crashes:

GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) rub
Undefined command: "rub".  Try "help".
(gdb) run
Starting program: /usr/local/bin/rtorrent 
[Thread debugging using libthread_db enabled]
rtorrent: View::filter_download(...) could not find download.

Program exited with code 0377.
(gdb) 

I added all the 3 patches for magnet links to the latest svn. Adding magnet links works as expected, but somehow rtorrent crashes after a few hours. Here is my gdb backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb784c6c0 (LWP 7176)]
0xb7e9436b in torrent::staticMap_read_bencode_c (
    buffer=0xbf9c3b8a "2:n42:n6ee1:q9:find_node1:t2:\005]1:v4:Az\005*1:y1:qes\231?\2371:y1:qe\n",
    bufferEnd=0xbf9c3bb9 "s\231?\2371:y1:qe\n", depth=3, values=0xbf9c4344, keys=@0x0, discard=false)
    at static_map.h:113
113       value_type         type() const          { return m_type; }
(gdb) backtrace full
#0  0xb7e9436b in torrent::staticMap_read_bencode_c (
    buffer=0xbf9c3b8a "2:n42:n6ee1:q9:find_node1:t2:\005]1:v4:Az\005*1:y1:qes\231?\2371:y1:qe\n",
    bufferEnd=0xbf9c3bb9 "s\231?\2371:y1:qe\n", depth=3, values=0xbf9c4344, keys=@0x0, discard=false)
    at static_map.h:113
No locals.
#1  0xb7e944c6 in torrent::staticMap_read_bencode_c (
    buffer=0xbf9c3b8a "2:n42:n6ee1:q9:find_node1:t2:\005]1:v4:Az\005*1:y1:qes\231?\2371:y1:qe\n",
    bufferEnd=0xbf9c3bb9 "s\231?\2371:y1:qe\n", depth=3, values=0xbf9c4344, keys=@0xa05b6f0,
    discard=<value optimized out>) at object_stream.cc:227
        strObj = {static mask_type = 4294967295, static mask_internal = 4294967295, static mask_public = 4294901760,
  static flag_unordered = 256, m_flags = 10, {m_value = -5201548030767005696, m_string = 0x0, m_list = 0x0,
    m_map = 0x0, m_sstring = {static npos = 4294967295, m_data = 0x0, m_length = 3083887520}}}
#2  0xb7e94632 in torrent::staticMap_read_bencode_c (
    buffer=0xbf9c3b89 "l2:n42:n6ee1:q9:find_node1:t2:\005]1:v4:Az\005*1:y1:qes\231?\2371:y1:qe\n",
    bufferEnd=0xbf9c3bb9 "s\231?\2371:y1:qe\n", depth=2, values=0xbf9c4344, keys=@0xa05b548, discard=false)
    at object_stream.cc:274
        keyObj = {static mask_type = 4294967295, static mask_internal = 4294967295, static mask_public = 4294901760,
  static flag_unordered = 256, m_flags = 5, {m_value = 20394556293, m_string = 0xbf9c3b85, m_list = 0xbf9c3b85,
    m_map = 0xbf9c3b85, m_sstring = {static npos = 4294967295,
      m_data = 0xbf9c3b85 "wantl2:n42:n6ee1:q9:find_node1:t2:\005]1:v4:Az\005*1:y1:qes\231?\2371:y1:qe\n",
      m_length = 4}}}
        cmp = <value optimized out>
        last = {<torrent::SimpleStringBase> = {static npos = 4294967295,
    m_data = 0xbf9c3b66 "target20:&&©\037qÁ¥©3\237dÎ\203©óle!&ð4:wantl2:n42:n6ee1:q9:find_node1:t2:\005]1:v4:Az\005*1:y1:qes\231?\2371:y1:qe\n", m_length = 6}, <No data fields>}
        discardThis = true
        strObj = {static mask_type = 4294967295, static mask_internal = 4294967295, static mask_public = 4294901760,
  static flag_unordered = 256, m_flags = 10, {m_value = -5201548030767005696, m_string = 0x0, m_list = 0x0,
    m_map = 0x0, m_sstring = {static npos = 4294967295, m_data = 0x0, m_length = 3083887520}}}
#3  0xb7e94632 in torrent::staticMap_read_bencode_c (
    buffer=0xbf9c3b48 "d2:id20:\216Àag3×3À\222\024L%Ûæ2ã\032\003\231:6:target20:&&©\037qÁ¥©3\237dÎ\203©óle!&ð4:wantl2:n42:n6ee1:q9:find_node1:t2:\005]1:v4:Az\005*1:y1:qes\231?\2371:y1:qe\n", bufferEnd=0xbf9c3bb9 "s\231?\2371:y1:qe\n",
    depth=1, values=0xbf9c4344, keys=@0xb7f2aa20, discard=false) at object_stream.cc:274
        keyObj = {static mask_type = 4294967295, static mask_internal = 4294967295, static mask_public = 4294901760,
  static flag_unordered = 256, m_flags = 5, {m_value = 7509654343, m_string = 0xbf9c3b47, m_list = 0xbf9c3b47,
    m_map = 0xbf9c3b47, m_sstring = {static npos = 4294967295,
      m_data = 0xbf9c3b47 "ad2:id20:\216Àag3×3À\222\024L%Ûæ2ã\032\003\231:6:target20:&&©\037qÁ¥©3\237dÎ\203©óle!&ð4:wantl2:n42:n6ee1:q9:find_node1:t2:\005]1:v4:Az\005*1:y1:qes\231?\2371:y1:qe\n", m_length = 1}}}
        cmp = <value optimized out>
        last = {<torrent::SimpleStringBase> = {static npos = 4294967295, m_data = 0xb7f0fe00 "",
    m_length = 0}, <No data fields>}
        discardThis = false
        strObj = {static mask_type = 4294967295, static mask_internal = 4294967295, static mask_public = 4294901760,
  static flag_unordered = 256, m_flags = 3, {m_value = -5191913007158117688, m_string = 0xbf9c3ac8,
    m_list = 0xbf9c3ac8, m_map = 0xbf9c3ac8, m_sstring = {static npos = 4294967295,
      m_data = 0xbf9c3ac8 "hD\234¿±çì·H;\234¿¹;\234¿", m_length = 3086130848}}}
#4  0xb7ece7b1 in torrent::DhtServer::event_read (this=0xa0ab0f0) at ./../torrent/object_stream.h:65
        buffer = "d1:ad2:id20:\216Àag3×3À\222\024L%Ûæ2ã\032\003\231:6:target20:&&©\037qÁ¥©3\237dÎ\203©óle!&ð4:wantl2:n42:n6ee1:q9:find_node1:t2:\005]1:v4:Az\005*1:y1:qes\231?\2371:y1:qe\n\000\000\000\t", '\0' <repeats 11 times>, "ô_зÅ)\020\b\000\000\000\000\bB\234¿·ì¾·,B\234¿Å)\020\b\000\000\000\000\000\000\000\000I#\020\b\000\000\000\000(B\234¿ÌÿÿÿH\r\000\000?"...
        read = <value optimized out>
        request = {static mask_type = 4294967295, static mask_internal = 4294967295, static mask_public = 4294901760,
  static flag_unordered = 256, m_flags = 0, {m_value = -4639758162604955828, m_string = 0x9a36674c,
    m_list = 0x9a36674c, m_map = 0x9a36674c, m_sstring = {static npos = 4294967295,
      m_data = 0x9a36674c <Address 0x9a36674c out of bounds>, m_length = 3214689416}}}
        sa = {static af_inet = 2, static pf_inet = <optimized out>, static af_inet6 = <optimized out>,
  static pf_inet6 = <optimized out>, static af_unspec = 0, static pf_unspec = <optimized out>,
  static af_local = <optimized out>, static pf_local = <optimized out>, {m_sockaddr = {sa_family = 2,
      sa_data = "Å\222[pβ\000\000\000\000\000\000\000"}, m_sockaddrInet = {sin_family = 2, sin_port = 37573,
      sin_addr = {s_addr = 2999873627}, sin_zero = "\000\000\000\000\000\000\000"}}}
        type = 63
        message = {<torrent::StaticMap<torrent::dht_keys, 15u>> = {static length = 15,
    static keyMap = {<torrent::StaticMapKeys> = {<std::vector<torrent::StaticMapKeys, std::allocator<torrent::StaticMapKeys> >> = {<std::_Vector_base<torrent::StaticMapKeys, std::allocator<torrent::StaticMapKeys> >> = {
            _M_impl = {<std::allocator<torrent::StaticMapKeys>> = {<__gnu_cxx::new_allocator<torrent::StaticMapKeys>> = {<No data fields>}, <No data fields>}, _M_start = 0xa05b548, _M_finish = 0xa05b628,
              _M_end_of_storage = 0xa05b648}}, <No data fields>}, m_key = {<torrent::SimpleStringBase> = {
            static npos = 4294967295, m_data = 0xb7f0b867 "root", m_length = 4}, <No data fields>}, m_indexBegin = 0,
        m_indexEnd = 15, m_type = torrent::StaticMapKeys::TYPE_DICT}, <No data fields>}, m_values = {{
        static mask_type = 4294967295, static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = 256, m_flags = 5, {m_value = 89114032976, m_string = 0xbf9c3b50, m_list = 0xbf9c3b50,
          m_map = 0xbf9c3b50, m_sstring = {static npos = 4294967295,
            m_data = 0xbf9c3b50 "\216Àag3×3À\222\024L%Ûæ2ã\032\003\231:6:target20:&&©\037qÁ¥©3\237dÎ\203©óle!&ð4:wantl2:n42:n6ee1:q9:find_node1:t2:\005]1:v4:Az\005*1:y1:qes\231?\2371:y1:qe\n", m_length = 20}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = 256, m_flags = 0, {m_value = 56004518312, m_string = 0xa2121a8, m_list = 0xa2121a8,
          m_map = 0xa2121a8, m_sstring = {static npos = 4294967295, m_data = 0xa2121a8 "Ô\230ò·\210",
            m_length = 13}}}, {static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760, static flag_unordered = 256, m_flags = 0, {m_value = 293118,
          m_string = 0x478fe, m_list = 0x478fe, m_map = 0x478fe, m_sstring = {static npos = 4294967295,
            m_data = 0x478fe <Address 0x478fe out of bounds>, m_length = 0}}}, {static mask_type = 4294967295,
        static mask_internal = 4294967295, static mask_public = 4294901760, static flag_unordered = 256, m_flags = 5, {
          m_value = 89114033007, m_string = 0xbf9c3b6f, m_list = 0xbf9c3b6f, m_map = 0xbf9c3b6f, m_sstring = {
            static npos = 4294967295,
            m_data = 0xbf9c3b6f "&&©\037qÁ¥©3\237dÎ\203©óle!&ð4:wantl2:n42:n6ee1:q9:find_node1:t2:\005]1:v4:Az\005*1:y1:qes\231?\2371:y1:qe\n", m_length = 20}}}, {static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760, static flag_unordered = 256, m_flags = 0, {m_value = -5191913007785447967,
          m_string = 0x9a37ede1, m_list = 0x9a37ede1, m_map = 0x9a37ede1, m_sstring = {static npos = 4294967295,
            m_data = 0x9a37ede1 <Address 0x9a37ede1 out of bounds>, m_length = 3086130848}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = 256, m_flags = 0, {m_value = -4639758852216723672, m_string = 0xa25e728,
          m_list = 0xa25e728, m_map = 0xa25e728, m_sstring = {static npos = 4294967295,
            m_data = 0xa25e728 "¸\202\006\n \203\006\nä°\n\nX\035\020\n\224{\006\nÀ\201\f\n¸é\026\nH)\022\n\220³\024\n@\027\n\n\020!\022\nd[!\nìm!\nä°\n\nH)\022\nH)\022\n\f¸!\nìm!\nü\222!\n@\027\n\n\234¹(\nä°\n\nT\016&\n\214î \n¼t\"\nL\r'\nT¬\"\nÔ\037'\n$x%\n\004.%\nDÂ%\n¬8!\ndº!\nd±\n\n\020!\022\nX«\024\n \025\020\n\210y\f\n\200á\026\nl\016&\nô\b%\nÌÔ%\nÜZ(\n\004\217'\n,\025)\ntß!\nlW'\nL¬$\n\024\001!\n\\Ñ$\n"..., m_length = 3214689256}}}, {static mask_type = 4294967295,
        static mask_internal = 4294967295, static mask_public = 4294901760, static flag_unordered = 256, m_flags = 0, {
          m_value = 38824961832, m_string = 0xa25e728, m_list = 0xa25e728, m_map = 0xa25e728, m_sstring = {
            static npos = 4294967295,
            m_data = 0xa25e728 "¸\202\006\n \203\006\nä°\n\nX\035\020\n\224{\006\nÀ\201\f\n¸é\026\nH)\022\n\220³\024\n@\027\n\n\020!\022\nd[!\nìm!\nä°\n\nH)\022\nH)\022\n\f¸!\nìm!\nü\222!\n@\027\n\n\234¹(\nä°\n\nT\016&\n\214î \n¼t\"\nL\r'\nT¬\"\nÔ\037'\n$x%\n\004.%\nDÂ%\n¬8!\ndº!\nd±\n\n\020!\022\nX«\024\n \025\020\n\210y\f\n\200á\026\nl\016&\nô\b%\nÌÔ%\nÜZ(\n\004\217'\n,\025)\ntß!\nlW'\nL¬$\n\024\001!\n\\Ñ$\n"..., m_length = 9}}}, {static mask_type = 4294967295,
        static mask_internal = 4294967295, static mask_public = 4294901760, static flag_unordered = 256, m_flags = 0, {
          m_value = 13488808817754808, m_string = 0xa0682b8, m_list = 0xa0682b8, m_map = 0xa0682b8, m_sstring = {
            static npos = 4294967295, m_data = 0xa0682b8 "áí7\232þx\004", m_length = 3140608}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = 256, m_flags = 0, {m_value = 731244828121104444, m_string = 0x3c, m_list = 0x3c,
          m_map = 0x3c, m_sstring = {static npos = 4294967295, m_data = 0x3c <Address 0x3c out of bounds>,
            m_length = 170256204}}}, {static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760, static flag_unordered = 256, m_flags = 0, {m_value = 730336307686403553,
          m_string = 0x9a37ede1, m_list = 0x9a37ede1, m_map = 0x9a37ede1, m_sstring = {static npos = 4294967295,
            m_data = 0x9a37ede1 <Address 0x9a37ede1 out of bounds>, m_length = 170044672}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = 256, m_flags = 0, {m_value = 168198800, m_string = 0xa068290, m_list = 0xa068290,
          m_map = 0xa068290, m_sstring = {static npos = 4294967295, m_data = 0xa068290 "", m_length = 0}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = 256, m_flags = 0, {m_value = 722408863708095259, m_string = 0xb7ea231b,
          m_list = 0xb7ea231b, m_map = 0xb7ea231b, m_sstring = {static npos = 4294967295,
            m_data = 0xb7ea231b "=ÿ\003", m_length = 168198920}}}, {static mask_type = 4294967295,
        static mask_internal = 4294967295, static mask_public = 4294901760, static flag_unordered = 256, m_flags = 0, {
          m_value = -5191913010202381544, m_string = 0xa287318, m_list = 0xa287318, m_map = 0xa287318, m_sstring = {
            static npos = 4294967295, m_data = 0xa287318 "h", m_length = 3086130848}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = 256, m_flags = 0, {m_value = -4639758646228549632, m_string = 0x0, m_list = 0x0,
          m_map = 0x0, m_sstring = {static npos = 4294967295, m_data = 0x0, m_length = 3214689304}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = 256, m_flags = 0, {m_value = 722408520111270344, m_string = 0xb7f2a9c8,
          m_list = 0xb7f2a9c8, m_map = 0xb7f2a9c8, m_sstring = {static npos = 4294967295,
            m_data = 0xb7f2a9c8 "(ç%\nPç%\n(é%\n", m_length = 168198840}}}}}, static data_size = 64,
  data = "áí7\232þx\004\000 s(\nð°\n\n\003\000\000\000 \236ò·¸\202\006\nPç%\n(D\234¿\210D\234¿ \236ò·\000\000\000\000\006¡Ã·:4ê·pD\234¿\000\000\000", data_end = 0xbf9c43f8 "áí7\232þx\004"}
        nodeId = (const class torrent::HashString *) 0x0
        total = 117
#5  0xb7e95730 in torrent::PollEPoll::perform (this=0xa0627a0) at poll_epoll.cc:166
        itr = (epoll_event *) 0xa0627c8
        last = (epoll_event *) 0xa0627d4
#6  0x080c44a8 in core::PollManagerEPoll::poll (this=0xa0626f0, timeout={m_time = 874432}) at poll_manager_epoll.cc:74
No locals.
#7  0x080829f9 in main (argc=1, argv=0xbf9c4634) at main.cc:321
        firstArg = 1
        e = <value optimized out>

I hope this helps to find the bug (if it is one).

Replying to anonymous:

I'm successfuly patched r1104 (dht-pex-static_map.diff, magnet-hex-hash.diff, magnet-uri.diff). When i adding any magnet link and press Ctrl+S, rtorrent waits some time, and crashes: {{{ ... rtorrent: View::filter_download(...) could not find download. }}}

OK, so it happens on Linux too. I'll really have to spend some time trying to track down this bug, I just wish I could reproduce it myself.

Replying to anonymous:

I added all the 3 patches for magnet links to the latest svn. Adding magnet links works as expected, but somehow rtorrent crashes after a few hours. Here is my gdb backtrace: [...] I hope this helps to find the bug (if it is one).

Yeah, it was a bug. I'd already experienced it myself and wrote a preliminary fix:

Index: /rtorrent/trunk/libtorrent/src/torrent/object_stream.cc
===================================================================
--- /rtorrent/trunk/libtorrent/src/torrent/object_stream.cc (revision 1366)
+++ /rtorrent/trunk/libtorrent/src/torrent/object_stream.cc (revision 1370)
@@ -258,8 +258,8 @@
 
       discardThis |= itr == keys.end();
-      int cmp = discardThis ? 0 : key.cmp(itr->key());
+      int cmp = discardThis ? -1 : key.cmp(itr->key());
       while (cmp > 0) {
         if (++itr == keys.end()) {
-          cmp = 0;
+          cmp = -1;
           discardThis = true;
           break;

The reason it happens is that Azureus 5.2 added a new dictionary to the DHT packet, which is not being ignored correctly, and rtorrent crashes while trying to handle it.

Let me know if it stops the crashes for you too, and I'll make a new release of the patchset.

To be honest the patches in dht-pex-static_map.diff seem a bit off. Why are you replacing the toggle message function? It now segfaults due to a null pointer

Replying to josef:

Yeah, it was a bug. I'd already experienced it myself and wrote a preliminary fix: The reason it happens is that Azureus 5.2 added a new dictionary to the DHT packet, which is not being ignored correctly, and rtorrent crashes while trying to handle it. Let me know if it stops the crashes for you too, and I'll make a new release of the patchset.

Thanks a lot! Seems to be stable now.

Hi,

Running rtorrent/libtorrent trunk r 1100 patched with dht-pex-static_map.diff, magnet-hex-hash.diff, magnet-uri.diff, and object_stream.cc patch. My OS is Debian based and using kernel 2.6.17.8.

I previously had segmentation faults and application aborts. Stability has improved with the latest patch but I'm still getting program aborts. I have an issue that the first time I load the magnet link, the link remains in closed state. DHT search says 'n/m nodes replied' but ends up saying 'announce failed'. Finally, rtorrent aborts saying 'rtorrent: View::filter_download(...) could not find download'.

My gdb backtrace is very limited in terms of error info. Do I need to compile using any specific debug parameters in order to get a full trace like the one above? Would realy like to help to bring this forward.

Replying to anonymous:

To be honest the patches in dht-pex-static_map.diff seem a bit off. Why are you replacing the toggle message function? It now segfaults due to a null pointer

Did you apply the object_stream.cc fix just above your post? That fixes one null pointer dereference problem. If that fix doesn't help, please post a backtrace of the segfault.

Replying to Jimmy:

I previously had segmentation faults and application aborts. Stability has improved with the latest patch but I'm still getting program aborts. I have an issue that the first time I load the magnet link, the link remains in closed state. DHT search says 'n/m nodes replied' but ends up saying 'announce failed'. Finally, rtorrent aborts saying 'rtorrent: View::filter_download(...) could not find download'.

Are you adding the magnet link with backspace or enter? With enter it would stay closed, as all other links added that way. With backspace (or load_start) it should start immediately, same with the actual download when the meta download finishes.

Or are you saying it's closed but still doing the DHT search??

I'll have to try and force a failed DHT announce, and see if that's the cause of the abort.

Replying to anonymous:

Are you adding the magnet link with backspace or enter? With enter it would stay closed, as all other links added that way. With backspace (or load_start) it should start immediately, same with the actual download when the meta download finishes. Or are you saying it's closed but still doing the DHT search?? I'll have to try and force a failed DHT announce, and see if that's the cause of the abort.

I'm adding with enter. Tried to search on how to add with backspace but can't figure it out. Just ends up deleting last character in link name.

As for DHT. Whenever I startup a new magnetic link, the GUI show the meta, e g D3935DD3B9535FE2FAAC5B7A86DE8A31CBDD4F87.meta instead of the actual torrent name. That's ok. Then DHT start searching for valid DHT clients and that is when I see I get a few replies but in the end the search in ended with msg 'announce failed'. And yes, I have defined a dedicated UDP port in my FW fwd to my rtorrent machine. Interesting is that rtorrent seems to abort when it gets the first DHT reply from another client. Cos when I restart rtorrent the meta is now replaced with the name of the actual torrent, and after some time I find other DHT clients and can start downloading. This sequence is repeated whenever I add new magnet links.

So I was looking for a way to get a more verbose output from gdb. And I suspect that I have to compile lbtorrent/rtorrent using debug parameters, but have been unsuccessful in finding out how to do so.

Replying to anonymous:

I'm adding with enter. Tried to search on how to add with backspace but can't figure it out. Just ends up deleting last character in link name.

Usually you press enter, insert the link and press enter again. This adds the torrent or magnet link to rtorrent, but does not start downloading yet. The other method is to press backspace, then insert the link and press enter (not backspace!). Now your torrent should be added and start downloading.

Replying to josef:

Replying to anonymous:

I'm successfuly patched r1104 (dht-pex-static_map.diff, magnet-hex-hash.diff, magnet-uri.diff). When i adding any magnet link and press Ctrl+S, rtorrent waits some time, and crashes: {{{ ... rtorrent: View::filter_download(...) could not find download. }}}

OK, so it happens on Linux too. I'll really have to spend some time trying to track down this bug, I just wish I could reproduce it myself.

just FYI, I have this bug too (Slackware 13.0)

gdb: rtorrent: View::filter_download(...) could not find download. Program exited with code 0377.

Replying to anonymous:

Interesting is that rtorrent seems to abort when it gets the first DHT reply from another client.

Actually that would probably be the reply which completes the meta-download. So it crashes when the meta download completes, in fact.

You could watch the peer list, and see if you (briefly) have a peer connected, and sending data. It makes more sense to have rtorrent crash when removing the meta download and re-adding the real download immediately, because there's a brief time where the given download doesn't exist.

What I don't understand is that it works for some people, and not for others. rtorrent isn't (yet) multi-threaded so I doubt it could be some race condition.

It is a mystery ‾\(o_O)/‾

So I was looking for a way to get a more verbose output from gdb. And I suspect that I have to compile lbtorrent/rtorrent using debug parameters, but have been unsuccessful in finding out how to do so.

Well, this isn't an easily debuggable crash, this is rtorrent exiting due to an internal_error exception. So you would need to set a breakpoint in the internal_error constructor. Compiling with debug symbols (also see http://libtorrent.rakshasa.no/wiki/CompilationHelp#Nosymbolinformationinbacktraces) will help though.

(gdb) br 'torrent::internal_error::internal_error(char const*)' 
Breakpoint 1 at 0x8b8a4: file exceptions.cc, line 60.
(gdb) br 'torrent::internal_error::internal_error(std::string const&)' 
Breakpoint 2 at 0x8ba34: file exceptions.cc, line 70.
(gdb) 

Then do a backtrace when the internal_error constructor is called.

I recompiled rtorrent/libtorrent using ./configure LDFLAGS=-rdynamic. However, like Josef suggested, it didn't give any more detailed information as of the cause of the abort.

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

Program exited with code 0377. (gdb)

Same behaviour like before: after pasting magnet link in only meta data is valuable in the GUI. On receiving reply from another client (meta data completion?) rtorrent aborts with above message. On second attempt to load same meta link to rtorrent meta download succeeds and download starts.

Please set the above breakpoints before starting rtorrent in gdb. That should give a proper backtrace.

The filter stuff happens both with backspace and enter, its only happening when the meta file have finished downloading seams like some kind of race condition because it only happens from time to time, no real pattern.

/T

Managed to get s small trace of an abort.

Breakpoint 1, internal_error (this=0x2bdf10, msg=0x177540 "View::filter_download(...) could not find download.")

at stl_alloc.h:652

652 allocator() throw() {} (gdb)

Didn't get a back-trace on that last post. Here is a new example of rtorrent aborting upon receiving final meta download.

Breakpoint 1, internal_error (this=0x2ade58, msg=0x177540 "View::filter_download(...) could not find download.")

at stl_alloc.h:652

652 allocator() throw() {} (gdb) backtrace #0 internal_error (this=0x2ade58, msg=0x177540 "View::filter_download(...) could not find download.") at stl_alloc.h:652 #1 0x0012fbb4 in core::View::filter_download (this=0x1ec508, download=0x2781b0) at view.cc:260 #2 0x000b5d3c in cmd_view_filter_download (download=0x3ebded00, rawArgs=@0x3ebded58) at stl_iterator.h:134 #3 0x00081cec in rak::ptr_fn2_t<torrent::Object, core::Download*, torrent::Object const&>::operator() (this=0x3ebded00,

arg1=0x3ebded00, arg2=@0x3ebded58) at functional_fun.h:215

#4 0x0015bc50 in rpc::CommandSlot?<core::Download*>::call_string (rawCommand=0x1aee60, target=0x2781b0,

rawArgs=@0x3ebded58) at memory:262

#5 0x001565a0 in rpc::CommandMap::call_command (this=0x1af8e8, key=0x229914 "view.filter_download", arg=@0x1aee60, target=

{<std::pair<int, void*>> = {first = 2, second = 0x2781b0}, third = 0x0}) at stl_tree.h:202

#6 0x0016435c in rpc::parse_command (target={<std::pair<int, void*>> = {first = 0, second = 0x3ebdef58}, third = 0x1},

first=0x1eb421 "", last=0x1eb421 "") at basic_string.h:717

#7 0x00164934 in rpc::parse_command_multiple (target=

{<std::pair<int, void*>> = {first = 2, second = 0x2781b0}, third = 0x0}, first=0x1eb421 "", last=0x1eb421 "")

at parse_commands.cc:148

#8 0x001540ec in rpc::CommandFunctionList::call (rawCommand=0x1eb118, target=

{<std::pair<int, void*>> = {first = 2, second = 0x2781b0}, third = 0x0}, args=@0x3ebdeed8) at basic_string.h:605

#9 0x001565a0 in rpc::CommandMap::call_command (this=0x1af8e8, key=0x176cb0 "event.download.hash_done", arg=@0x3ebdf398,

target={<std::pair<int, void*>> = {first = 2, second = 0x2781b0}, third = 0x0}) at stl_tree.h:202

#10 0x001562d8 in rpc::CommandMap::call_catch (this=0x1af8e8, key=0x3ebdf378 "", target=

{<std::pair<int, void*>> = {first = 2, second = 0x2781b0}, third = 0x0}, args=@0x3ebdf398,

err=0x176718 "Download event action failed: ") at command_map.cc:119

#11 0x00113968 in core::DownloadList::hash_done (this=0x1d2ab0, download=0x2781b0) at object.h:90 #12 0x00119290 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=0x11307c) at mem_fun.h:1839

#13 0x0011d100 in sigc::internal::signal_emit0<void, sigc::nil>::emit (impl=0x2987a8) at stl_list.h:174 ---Type <return> to continue, or q <return> to quit--- #14 0x2019f8e0 in torrent::DownloadWrapper::receive_initial_hash (this=0x2ad308) at signal.h:1608 #15 0x201a1ee4 in rak::mem_fn0_t<torrent::DownloadWrapper?, void>::operator() (this=0x26eab8) at functional_fun.h:229 #16 0x2014adb8 in torrent::perform () at memory:262 #17 0x0012ccc0 in core::PollManagerEPoll::poll (this=0x1d9630, timeout={m_time = 654265}) at poll_manager_epoll.cc:67 #18 0x000bcf30 in main (argc=1, argv=0x3ebdf8c4) at main.cc:137 (gdb)

After restarting rtorrent and re-pasting in the magnet link of the torrent that caused the crash, I could see that when the magnet meta data in the GUI changed to the actual torrent file there where NO CLIENTS VISUAL in the peer-list for that torrent. Kind of strange.

Anyway. I added yet another magnet link and got a new crash and trace. Here it is.

Breakpoint 1, internal_error (this=0x2d7e10, msg=0x177540 "View::filter_download(...) could not find download.")

at stl_alloc.h:652

652 allocator() throw() {} (gdb) backtrace

#0 internal_error (this=0x2d7e10, msg=0x177540 "View::filter_download(...) could not find download.") at stl_alloc.h:652 #1 0x0012fbb4 in core::View::filter_download (this=0x1ec508, download=0x2ccdd8) at view.cc:260 #2 0x000b5d3c in cmd_view_filter_download (download=0x3ed26d00, rawArgs=@0x3ed26d58) at stl_iterator.h:134 #3 0x00081cec in rak::ptr_fn2_t<torrent::Object, core::Download*, torrent::Object const&>::operator() (this=0x3ed26d00,

arg1=0x3ed26d00, arg2=@0x3ed26d58) at functional_fun.h:215

#4 0x0015bc50 in rpc::CommandSlot?<core::Download*>::call_string (rawCommand=0x1aee60, target=0x2ccdd8,

rawArgs=@0x3ed26d58) at memory:262

#5 0x001565a0 in rpc::CommandMap::call_command (this=0x1af8e8, key=0x219cbc "view.filter_download", arg=@0x1aee60, target=

{<std::pair<int, void*>> = {first = 2, second = 0x2ccdd8}, third = 0x0}) at stl_tree.h:202

#6 0x0016435c in rpc::parse_command (target={<std::pair<int, void*>> = {first = 0, second = 0x3ed26f58}, third = 0x1},

first=0x1eb421 "", last=0x1eb421 "") at basic_string.h:717

#7 0x00164934 in rpc::parse_command_multiple (target=

{<std::pair<int, void*>> = {first = 2, second = 0x2ccdd8}, third = 0x0}, first=0x1eb421 "", last=0x1eb421 "")

at parse_commands.cc:148

#8 0x001540ec in rpc::CommandFunctionList::call (rawCommand=0x1eb118, target=

{<std::pair<int, void*>> = {first = 2, second = 0x2ccdd8}, third = 0x0}, args=@0x3ed26ed8) at basic_string.h:605

#9 0x001565a0 in rpc::CommandMap::call_command (this=0x1af8e8, key=0x176cb0 "event.download.hash_done", arg=@0x3ed27398,

target={<std::pair<int, void*>> = {first = 2, second = 0x2ccdd8}, third = 0x0}) at stl_tree.h:202

#10 0x001562d8 in rpc::CommandMap::call_catch (this=0x1af8e8, key=0x3ed27378 "", target=

{<std::pair<int, void*>> = {first = 2, second = 0x2ccdd8}, third = 0x0}, args=@0x3ed27398,

err=0x176718 "Download event action failed: ") at command_map.cc:119

#11 0x00113968 in core::DownloadList::hash_done (this=0x1d2ab0, download=0x2ccdd8) at object.h:90 #12 0x00119290 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=0x11307c) at mem_fun.h:1839

#13 0x0011d100 in sigc::internal::signal_emit0<void, sigc::nil>::emit (impl=0x273048) at stl_list.h:174

---Type <return> to continue, or q <return> to quit---

#14 0x2019f8e0 in torrent::DownloadWrapper::receive_initial_hash (this=0x29f248) at signal.h:1608 #15 0x201a1ee4 in rak::mem_fn0_t<torrent::DownloadWrapper?, void>::operator() (this=0x29d038) at functional_fun.h:229 #16 0x2014adb8 in torrent::perform () at memory:262 #17 0x0012ccc0 in core::PollManagerEPoll::poll (this=0x1d9630, timeout={m_time = 350959}) at poll_manager_epoll.cc:67 #18 0x000bcf30 in main (argc=1, argv=0x3ed278c4) at main.cc:137 (gdb)

OK, thanks for the trace. I found the problem, it crashes if you set "check_hash=yes", because the code couldn't deal with the extra hash check.

Here's the fix:

Index: rtorrent/src/core/download_list.cc
===================================================================
--- rtorrent/src/core/download_list.cc  (revision 1370)
+++ rtorrent/src/core/download_list.cc  (working copy)
@@ -454,12 +454,12 @@
   int64_t hashing = rpc::call_command_value("d.get_hashing", rpc::make_target(download));
   rpc::call_command_set_value("d.set_hashing", Download::variable_hashing_stopped, rpc::make_target(download));
 
+  if (download->is_done() && download->download()->is_meta_download())
+    return process_meta_download(download);
+
   switch (hashing) {
   case Download::variable_hashing_initial:
   case Download::variable_hashing_rehash:
-    if (download->is_done() && download->download()->is_meta_download())
-      return process_meta_download(download);
-
     // Normal re/hashing.
 
     // If the download was previously completed but the files were

I'll make a new release of the patches with these two fixes added, either today or tomorrow.

Hi Josef and fellow rtorrent lovers,

The latest patch seem to resolve the issue of program aborts (my system: Debian-based NAS, kernel 2.6.17).

I have recompiled rtorrent and can no-longer reproduce the fault. Below is the sequence of how a magnet link is loaded to rtorrent, meta data updated, and download initiated.

To load a magnet link, copy the link from your browser, press Ctrl+Backspace in rtorrent to get load_start prompt, paste in the link and press Enter.

One remaining issue is that the torrent list never shows any DHT clients (always S/L: 0/0). This doesn't impact the ability to download, but seem to indicate that there is a remaining fault in rtorrent's DHT handling. Or have I misunderstood something?

Big THX to Josef for being so quick to come up with a resolution!

PEER-LIST SCREEN INITIALLY

*** EB3FEFA135584789281F3372AFFA8B1A7CBEDB2E.meta *** IP UP DOWN PEER C/RE/LO QS DONE REQ SNUB FAILED <deleted> 0.0 0.0 0.0 r/cn/ci 0/0 100 uTorrent 1.8.4.0

Peers: 0(0) Min/Max: 10/40 Uploads: 15 U/I/C/A: 0/0/0/0 Failed: 0

TRACKER STATUS UPDTATE SEQUENCE Below shows hos tracker status is updated over time.

[C:0] Tracker[1:1]: Connecting to  dht:// [Searching: 11/16 nodes replied] ... [C:0] Tracker[1:1]: Connecting to  dht:// [Searching: 13/29 nodes replied] ... [C:0] Tracker[1:1]: Connecting to  dht:// [Announcing: 1/3 nodes replied] (peer-list still empty; still meta name, not torrent name, displayed) ..

TRACKER LIST SCREEN After the tracker update sequence has indicated that a few clients has announced their existence, my track list contains lots of HTTP clients but no DHT ones.

Trackers: [Key: 18bdee8c] 0:  http://tracker.publicbt.com/announce

Id: Focus: no Enabled: yes Open: no S/L: 1588/301

1:  dht://

Id: Focus: no Enabled: yes Open: no S/L: 0/0

INFO SCREEN Initially the info screen does not contain any 'tied to file info', nor a proper file name.

Directory: /<path>/doing Base Path: /<path>/doing/EB3FEFA135584789281F3372AFFA8B1A7CBEDB2E.meta Tied to file: File stats: single 1 files

PEER-LIST SCREEN UPDATED Waiting to download final meta data. And suddenly a client appears in the peer list.

*** EB3FEFA135584789281F3372AFFA8B1A7CBEDB2E.meta *** IP UP DOWN PEER C/RE/LO QS DONE REQ SNUB FAILED <deleted> 0.0 0.0 0.0 r/cn/ci 0/0 100 uTorrent 1.8.4.0

And voila! After some time the meta data is updated. (However, on later attempt I received the final meta data BEFORE any clients were seen in Peer-List, so this sequence may vary.)

INFO SCREEN Now the torrent file name is updated, and 'tied to file' indicates the meta file.

*** <deleted torrent file name> *** Name: <deleted torrent file name> Local id: -lt0C50-a%82%08%EAz%C4%ED%18%A6%0C%1E%3D Info hash: EB3FEFA135584789281F3372AFFA8B1A7CBEDB2E Created: 01/01/1970 7:00:00

Directory: /<path>/doing/<deleted torrent file name> Base Path: /<path>/doing/<deleted torrent file name> Tied to file: /<path>/doing/EB3FEFA135584789281F3372AFFA8B1A7CBEDB2E.meta File stats: multi 22 files

TRACKER LIST SCREEN AFTER META DATA DOWNLOAD COMPLETED I would have expected to see DHT clients listed here, but it still just HTTP ones. Bug?

*** <deleted torrent file name> *** Trackers: [Key: 2082dc2b] 0:  http://tracker.publicbt.com/announce

Id: Focus: no Enabled: yes Open: no S/L: 1580/299

1:  dht://

Id: Focus: no Enabled: yes Open: no S/L: 0/0

Replying to Jimmy:

One remaining issue is that the torrent list never shows any DHT clients (always S/L: 0/0). This doesn't impact the ability to download, but seem to indicate that there is a remaining fault in rtorrent's DHT handling. Or have I misunderstood something?

Because DHT is not a real tracker, that information simply does not exist. There's no way to know whether a peer is a seed, until we connect to it.

Many other trackers do not provide that information either. It's not a problem.

rtorrent now starts crashing with the following error

Peer-supplied metadata size mismatch

I try to get a backtrace of this. What does the error mean?

I'm getting crashes with the following error: rtorrent: DhtRouter::get_tracker did not actually insert tracker.

These happened with the original patches, and with the two additional patches (object_stream and download_list). Help!

Here's the gdb backtrace, if it helps:

Breakpoint 1, internal_error (this=0x185028,
    msg=0x4016d1dc "DhtRouter::get_tracker did not actually insert tracker.")
    at exceptions.cc:50
50      internal_error::internal_error(const char* msg) : m_msg(msg) {
(gdb) backtrace full
#0  internal_error (this=0x185028,
    msg=0x4016d1dc "DhtRouter::get_tracker did not actually insert tracker.")
    at exceptions.cc:50
No locals.
#1  0x401171c8 in torrent::DhtRouter::get_tracker (this=<value optimized out>,
    hash=@0xbedb8a0e, create=true) at dht_router.cc:169
        res = {
  first = {<Internal::hashtable_iterator<std::pair<const torrent::HashString, torrent::DhtTracker*>,false,false>> = {<Internal::hashtable_iterator_base<std::pair<const torrent::HashString, torrent::DhtTracker*>,false>> = {
        m_cur_node = 0x103e50,
        m_cur_bucket = 0x134bcc}, <No data fields>}, <No data fields>},
  second = false}
#2  0x40120060 in torrent::DhtServer::create_announce_peer_response (
    this=0x134108, req=@0xbedb91e0, sa=0xbedb92d8, reply=<value optimized out>)
    at dht_server.cc:345
        tracker = (torrent::DhtTracker *) 0xbedb8a0e
#3  0x401207d0 in torrent::DhtServer::process_query (this=0x134108,
    id=@0xbedb89ec, sa=0xbedb92d8, msg=@0xbedb91e0) at dht_server.cc:285
        query = {<torrent::SimpleStringBase> = {static npos = 4294967295,
    m_data = 0xbedb8a47 "announce_peer1:t8: çj)ks(w1:y1:qe",
    m_length = 13}, <No data fields>}
        reply = {<torrent::StaticMap<torrent::dht_keys,15u>> = {
    static length = 15,
    static keyMap = {<torrent::StaticMapKeys> = {<std::vector<torrent::StaticMapKeys,std::allocator<torrent::StaticMapKeys> >> = {<std::_Vector_base<torrent::StaticMapKeys,std::allocator<torrent::StaticMapKeys> >> = {
            _M_impl = {<std::allocator<torrent::StaticMapKeys>> = {<__gnu_cxx::new_allocator<torrent::StaticMapKeys>> = {<No data fields>}, <No data fields>},
              _M_start = 0xf76e8, _M_finish = 0xf77c8,
              _M_end_of_storage = 0xf77e8}}, <No data fields>},
        m_key = {<torrent::SimpleStringBase> = {static npos = 4294967295,
            m_data = 0x4016ac9c "root", m_length = 4}, <No data fields>},
        m_indexBegin = 0, m_indexEnd = 15,
        m_type = torrent::StaticMapKeys::TYPE_DICT}, <No data fields>},
    m_values = {{static mask_type = 4294967295,
        static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {
          m_value = -4694006004120319520, m_string = 0xbedb89e0,
          m_list = 0xbedb89e0, m_map = 0xbedb89e0, m_sstring = {
            static npos = 4294967295,
            m_data = 0xbedb89e0 "d1:ad2:id20:J%s\237Çvakáïä[áÄ*x÷p\22349:info_hash20:¶}öº\0036z\215ùßÞ^", m_length = 3202058856}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295,
---Type <return> to continue, or q <return> to quit---
        static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {m_value = 0,
          m_string = 0x0, m_list = 0x0, m_map = 0x0, m_sstring = {
            static npos = 4294967295, m_data = 0x0, m_length = 0}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {m_value = 0,
          m_string = 0x0, m_list = 0x0, m_map = 0x0, m_sstring = {
            static npos = 4294967295, m_data = 0x0, m_length = 0}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {
          m_value = 7497027376, m_string = 0xbedb8f30, m_list = 0xbedb8f30,
          m_map = 0xbedb8f30, m_sstring = {static npos = 4294967295,
            m_data = 0xbedb8f30 "", m_length = 1}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {
          m_value = 4618450368580288516, m_string = 0x4, m_list = 0x4,
          m_map = 0x4, m_sstring = {static npos = 4294967295,
            m_data = 0x4 <Address 0x4 out of bounds>,
            m_length = 1075316772}}}, {static mask_type = 4294967295,
        static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {
          m_value = 4295980968, m_string = 0xf77a8, m_list = 0xf77a8,
          m_map = 0xf77a8, m_sstring = {static npos = 4294967295,
            m_data = 0xf77a8 "°q\r", m_length = 1}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {
          m_value = -1092908628, m_string = 0xbedb89ac, m_list = 0xbedb89ac,
          m_map = 0xbedb89ac, m_sstring = {static npos = 4294967295,
            m_data = 0xbedb89ac "È\223Û¾\004", m_length = 4294967295}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {m_value = 0,
          m_string = 0x0, m_list = 0x0, m_map = 0x0, m_sstring = {
            static npos = 4294967295, m_data = 0x0, m_length = 0}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {
          m_value = 4618327781623797592, m_string = 0x11758, m_list = 0x11758,
          m_map = 0x11758, m_sstring = {static npos = 4294967295,
            m_data = 0x11758 "", m_length = 1075288230}}}, {
---Type <return> to continue, or q <return> to quit---
        static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {
          m_value = -4694009029904715580, m_string = 0x400db0c4,
          m_list = 0x400db0c4, m_map = 0x400db0c4, m_sstring = {
            static npos = 4294967295,
            m_data = 0x400db0c4 "\020¡\237å\n \217àX°\213âø0\033åô",
            m_length = 3202058152}}}, {static mask_type = 4294967295,
        static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {
          m_value = -4694006011617345536, m_string = 0x0, m_list = 0x0,
          m_map = 0x0, m_sstring = {static npos = 4294967295, m_data = 0x0,
            m_length = 3202058855}}}, {static mask_type = 4294967295,
        static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {
          m_value = 7497026147, m_string = 0xbedb8a63, m_list = 0xbedb8a63,
          m_map = 0xbedb8a63, m_sstring = {static npos = 4294967295,
            m_data = 0xbedb8a63 "y1:qe", m_length = 1}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {
          m_value = 4478912156395864, m_string = 0xfe958, m_list = 0xfe958,
          m_map = 0xfe958, m_sstring = {static npos = 4294967295,
            m_data = 0xfe958 "¼Ë\027@\006", m_length = 1042828}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {
          m_value = 4478688818108880, m_string = 0x1019d0, m_list = 0x1019d0,
          m_map = 0x1019d0, m_sstring = {static npos = 4294967295,
            m_data = 0x1019d0 "\t", m_length = 1042776}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {
          m_value = 531304634384384, m_string = 0x0, m_list = 0x0,
          m_map = 0x0, m_sstring = {static npos = 4294967295, m_data = 0x0,
            m_length = 123704}}}}}, static data_size = 64,
  data = "\000\b\000\000\005\000\000\000à\221Û¾¬\211Û¾¬\211Û¾¬\211Û¾c\212Û¾\001\000\000\000c\212Û¾\001\000\000\000X\027\001\000ïy\f\000Ø\210Û¾ôâ\001\000\224\210Û¾\000\000\000", data_end = 0xbedb8894 ""}
#4  0x401216cc in torrent::DhtServer::event_read (this=0x134108)
    at dht_server.cc:740
        buffer = "d1:ad2:id20:J%s\237Çvakáïä[áÄ*x÷p\22349:info_hash20:¶}öº\0036z\215ùßÞ^\000ètë&\024*\2304:porti21066e5:token8:>j\004b\026h\023Þe1:q13:announce_peer1:t8: çj)ks(w1:y1:qe", '\0' <repeats 12 times>, " \000\000\0004\221Û¾\va\f\0---Type <return> to continue, or q <return> to quit---
00XÙ3@@Þ@@m_\f\000ð`\f\000\000\000\000\000%\000\000\000L\220Û¾ÿÿi_\f\000L\220Û¾H\220"...
        read = <value optimized out>
        request = {static mask_type = 4294967295,
  static mask_internal = 4294967295, static mask_public = 4294901760,
  static flag_unordered = <optimized out>, m_flags = 0, {m_value = 0,
    m_string = 0x0, m_list = 0x0, m_map = 0x0, m_sstring = {
      static npos = 4294967295, m_data = 0x0, m_length = 0}}}
        sa = {static af_inet = 2, static pf_inet = 2,
  static af_inet6 = <optimized out>, static pf_inet6 = <optimized out>,
  static af_unspec = 0, static pf_unspec = <optimized out>,
  static af_local = <optimized out>, static pf_local = <optimized out>, {
    m_sockaddr = {sa_family = 2,
      sa_data = "RJ½\0323\026\000\000\000\000\000\000\000"}, m_sockaddrInet = {
      sin_family = 2, sin_port = 19026, sin_addr = {s_addr = 372447933},
      sin_zero = "\000\000\000\000\000\000\000"}}}
        type = 113
        message = {<torrent::StaticMap<torrent::dht_keys,15u>> = {
    static length = 15,
    static keyMap = {<torrent::StaticMapKeys> = {<std::vector<torrent::StaticMapKeys,std::allocator<torrent::StaticMapKeys> >> = {<std::_Vector_base<torrent::StaticMapKeys,std::allocator<torrent::StaticMapKeys> >> = {
            _M_impl = {<std::allocator<torrent::StaticMapKeys>> = {<__gnu_cxx::new_allocator<torrent::StaticMapKeys>> = {<No data fields>}, <No data fields>},
              _M_start = 0xf76e8, _M_finish = 0xf77c8,
              _M_end_of_storage = 0xf77e8}}, <No data fields>},
        m_key = {<torrent::SimpleStringBase> = {static npos = 4294967295,
            m_data = 0x4016ac9c "root", m_length = 4}, <No data fields>},
        m_indexBegin = 0, m_indexEnd = 15,
        m_type = torrent::StaticMapKeys::TYPE_DICT}, <No data fields>},
    m_values = {{static mask_type = 4294967295,
        static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 5, {
          m_value = 89101404652, m_string = 0xbedb89ec, m_list = 0xbedb89ec,
          m_map = 0xbedb89ec, m_sstring = {static npos = 4294967295,
            m_data = 0xbedb89ec "J%s\237Çvakáïä[áÄ*x÷p\22349:info_hash20:¶}öº\0036z\215ùßÞ^", m_length = 20}}}, {static mask_type = 4294967295,
        static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 5, {
          m_value = 89101404686, m_string = 0xbedb8a0e, m_list = 0xbedb8a0e,
          m_map = 0xbedb8a0e, m_sstring = {static npos = 4294967295,
            m_data = 0xbedb8a0e "¶}öº\0036z\215ùßÞ^", m_length = 20}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760,
---Type <return> to continue, or q <return> to quit---
        static flag_unordered = <optimized out>, m_flags = 1, {
          m_value = 21066, m_string = 0x524a, m_list = 0x524a, m_map = 0x524a,
          m_sstring = {static npos = 4294967295,
            m_data = 0x524a <Address 0x524a out of bounds>, m_length = 0}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {
          m_value = 6779231121674648, m_string = 0xbedb9198,
          m_list = 0xbedb9198, m_map = 0xbedb9198, m_sstring = {
            static npos = 4294967295,
            m_data = 0xbedb9198 "à\221Û¾È\223Û¾\024\222Û¾X\027\001",
            m_length = 1578412}}}, {static mask_type = 4294967295,
        static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 5, {
          m_value = 37561797176, m_string = 0xbedb8a38, m_list = 0xbedb8a38,
          m_map = 0xbedb8a38, m_sstring = {static npos = 4294967295,
            m_data = 0xbedb8a38 ">j\004b\026h\023Þe1:q13:announce_peer1:t8: çj)ks(w1:y1:qe", m_length = 8}}}, {static mask_type = 4294967295,
        static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {m_value = 0,
          m_string = 0x0, m_list = 0x0, m_map = 0x0, m_sstring = {
            static npos = 4294967295, m_data = 0x0, m_length = 0}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {m_value = 0,
          m_string = 0x0, m_list = 0x0, m_map = 0x0, m_sstring = {
            static npos = 4294967295, m_data = 0x0, m_length = 0}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 5, {
          m_value = 59036633671, m_string = 0xbedb8a47, m_list = 0xbedb8a47,
          m_map = 0xbedb8a47, m_sstring = {static npos = 4294967295,
            m_data = 0xbedb8a47 "announce_peer1:t8: çj)ks(w1:y1:qe",
            m_length = 13}}}, {static mask_type = 4294967295,
        static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {m_value = 0,
          m_string = 0x0, m_list = 0x0, m_map = 0x0, m_sstring = {
            static npos = 4294967295, m_data = 0x0, m_length = 0}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {m_value = 0,
          m_string = 0x0, m_list = 0x0, m_map = 0x0, m_sstring = {
            static npos = 4294967295, m_data = 0x0, m_length = 0}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295,
---Type <return> to continue, or q <return> to quit---
        static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {m_value = 0,
          m_string = 0x0, m_list = 0x0, m_map = 0x0, m_sstring = {
            static npos = 4294967295, m_data = 0x0, m_length = 0}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {
          m_value = -8794855169683326591, m_string = 0x47981,
          m_list = 0x47981, m_map = 0x47981, m_sstring = {
            static npos = 4294967295, m_data = 0x47981 "",
            m_length = 2247255506}}}, {static mask_type = 4294967295,
        static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 5, {
          m_value = 46151731799, m_string = 0xbedb8a57, m_list = 0xbedb8a57,
          m_map = 0xbedb8a57, m_sstring = {static npos = 4294967295,
            m_data = 0xbedb8a57 "8: çj)ks(w1:y1:qe", m_length = 10}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 0, {
          m_value = 4578677902960082, m_string = 0x85f265d2,
          m_list = 0x85f265d2, m_map = 0x85f265d2, m_sstring = {
            static npos = 4294967295,
            m_data = 0x85f265d2 <Address 0x85f265d2 out of bounds>,
            m_length = 1066056}}}, {static mask_type = 4294967295,
        static mask_internal = 4294967295, static mask_public = 4294901760,
        static flag_unordered = <optimized out>, m_flags = 5, {
          m_value = 7497026150, m_string = 0xbedb8a66, m_list = 0xbedb8a66,
          m_map = 0xbedb8a66, m_sstring = {static npos = 4294967295,
            m_data = 0xbedb8a66 "qe", m_length = 1}}}}},
  static data_size = 64,
  data = "p\a\030@£\234\003\000\000\000\000\000¨\202\f@HD\020\000À\222Û¾Úg\020\000\000\000\000\000È\223Û¾ÿÿ\003\000\000\000\230\025\030\000\004\000\000\000\001\000\000\000X\027\001\000½º\027@", data_end = 0xbedb9294 "p\a\030@£\234\003"}
        nodeId = (const torrent::HashString *) 0xbedb89ec
        total = 136
#5  0x400ddcf0 in torrent::PollEPoll::perform (this=0xfe958)
    at poll_epoll.cc:166
        itr = (epoll_event *) 0xfe980
        last = (epoll_event *) 0xfe98c
#6  0x000879c8 in core::PollManagerEPoll::poll (this=0xfe8a8, timeout=
      {m_time = 4733}) at poll_manager_epoll.cc:74
No locals.
#7  0x00045768 in main (argc=1, argv=0xbedb95a4) at main.cc:321
        firstArg = 1
---Type <return> to continue, or q <return> to quit---
        e = <value optimized out>
(gdb)

Replying to Jimmy:

[...] The latest patch seem to resolve the issue of program aborts [...]

Also works for me.

Big thanks to the author.

Replying to Mr. G:

rtorrent now starts crashing with the following error {{{ Peer-supplied metadata size mismatch }}} I try to get a backtrace of this. What does the error mean?

It means various peers disagree about the size of the metadata download. This means a peer either has a bug, or is a malicious peer.

However, it should not crash. It should only disconnect the peer which disagrees. Apparently the exception is not being caught correctly in all cases, so a backtrace of the crash would be helpful. You will need to set these breakpoints:

(gdb) br 'torrent::storage_error::storage_error(char const*)' 
(gdb) br 'torrent::storage_error::storage_error(std::string const&)' 

However, storage errors are also thrown in some genuine contexts during chunk handling, so before posting the backtrace, make sure the argument holds the "Peer-supplied metadata size mismatch" text (IOW it should appear in the backtrace). Otherwise continue with "c" until that particular storage error is thrown.

Replying to anonymous:

I'm getting crashes with the following error: rtorrent: DhtRouter::get_tracker did not actually insert tracker. These happened with the original patches, and with the two additional patches (object_stream and download_list).

I can only explain that as a bug in std::tr1::unordered_map. What g++ and libstdc++ versions are you using?

The code tries to find the given hash in the unordered_map. When it's not found, it tries to insert it. However, unordered_map returns that the hash could not be inserted because it already existed (any other problem would raise an exception instead). This is not possible according to the specs, and hence must be a bug.

You can try upgrading your g++ and libstdc++, or as a work-around you can configure libtorrent to not use the TR1 extensions, with

./configure --disable-std_tr1

AFAIK this is not a crash... it just quits the program printing "Peer-supplied metadata size mismatch" and thats it.

Happend to me more than twice today.

OK, I've updated the patches for the latest libtorrent/rtorrent version, revision 1105, and included all the above changes and fixes, as well an as-yet unpublished fix for a crash when you quit rtorrent with unfinished meta-downloads. (No fix for "Peer-supplied metadata size mismatch" yet.)

Follow the original instructions (except with revision 1105 of course) to apply them.

The patch works! I'm totally new to rtorrent (got it to day) and it's beautiful! Thanx! //Simon

I compiled revision 1105 with patches and with LDFLAGS=-rdynamic. I've set the two breakpoints, but rtorrents still exits without stopping at the mentioned breakpoints:

GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
(gdb) br 'torrent::storage_error::storage_error(char const*)'
Function "torrent::storage_error::storage_error(char const*)" not defined.
Make breakpoint pending on future shared library load? (y or [n])
(gdb) br 'torrent::storage_error::storage_error(std::string const&)'
Function "torrent::storage_error::storage_error(std::string const&)" not defined.
Make breakpoint pending on future shared library load? (y or [n])
(gdb) run
Starting program: /usr/local/bin/rtorrent
[Thread debugging using libthread_db enabled]
rtorrent: Peer-supplied metadata size mismatch.

Program exited with code 0377.
(gdb)

ran the code from the previous post again, but now with the breakpoints referring to the lines in the source code:

(gdb) br download_main.cc:464
(gdb) br download_main.cc:467

Now the debugger stopped just before the exit. This is the backtrace:

Breakpoint 2, torrent::DownloadMain::set_metadata_size (this=<value optimized out>, size=52276) at download_main.cc:467
467           throw storage_error("Peer-supplied metadata size mismatch.");
(gdb) bt full
#0  torrent::DownloadMain::set_metadata_size (this=<value optimized out>, size=52276) at download_main.cc:467
No locals.
#1  0x00007f7494006112 in torrent::ProtocolExtension::parse_handshake (this=0x271da20) at extensions.cc:368
        message = {<torrent::StaticMap<torrent::ext_handshake_keys, 7ul>> = {static length = 7,
    static keyMap = {<torrent::StaticMapKeys> = {<std::vector<torrent::StaticMapKeys, std::allocator<torrent::StaticMapKeys> >> = {<std::_Vector_base<torrent::StaticMapKeys, std::allocator<torrent::StaticMapKeys> >> = {
            _M_impl = {<std::allocator<torrent::StaticMapKeys>> = {<__gnu_cxx::new_allocator<torrent::StaticMapKeys>> = {<No data fields>}, <No data fields>}, _M_start = 0x2538350, _M_finish = 0x25384d0, _M_end_of_storage = 0x2538550}}, <No data fields>}, m_key = {<torrent::SimpleStringBase> = {
            static npos = 18446744073709551615, m_data = 0x7f7494023187 "root", m_length = 4}, <No data fields>}, m_indexBegin = 0, m_indexEnd = 7,
        m_type = torrent::StaticMapKeys::TYPE_DICT}, <No data fields>}, m_values = {{static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760, static flag_unordered = <optimized out>, m_flags = 1, {m_value = 0, m_string = 0x0, m_list = 0x0, m_map = 0x0,
          m_sstring = {static npos = 18446744073709551615, m_data = 0x0, m_length = 0}}}, {static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760, static flag_unordered = <optimized out>, m_flags = 1, {m_value = 2, m_string = 0x2, m_list = 0x2, m_map = 0x2,
          m_sstring = {static npos = 18446744073709551615, m_data = 0x2 <Address 0x2 out of bounds>, m_length = 140138683006297}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295, static mask_public = 4294901760, static flag_unordered = <optimized out>,
        m_flags = 1, {m_value = 1, m_string = 0x1, m_list = 0x1, m_map = 0x1, m_sstring = {static npos = 18446744073709551615,
            m_data = 0x1 <Address 0x1 out of bounds>, m_length = 174}}}, {static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760, static flag_unordered = <optimized out>, m_flags = 1, {m_value = 52276, m_string = 0xcc34, m_list = 0xcc34,
          m_map = 0xcc34, m_sstring = {static npos = 18446744073709551615, m_data = 0xcc34 <Address 0xcc34 out of bounds>, m_length = 0}}}, {
        static mask_type = 4294967295, static mask_internal = 4294967295, static mask_public = 4294901760, static flag_unordered = <optimized out>,
        m_flags = 1, {m_value = 57448, m_string = 0xe068, m_list = 0xe068, m_map = 0xe068, m_sstring = {static npos = 18446744073709551615,
            m_data = 0xe068 <Address 0xe068 out of bounds>, m_length = 39508736}}}, {static mask_type = 4294967295, static mask_internal = 4294967295,
        static mask_public = 4294901760, static flag_unordered = <optimized out>, m_flags = 1, {m_value = 255, m_string = 0xff, m_list = 0xff, m_map = 0xff,
          m_sstring = {static npos = 18446744073709551615, m_data = 0xff <Address 0xff out of bounds>, m_length = 174}}}, {static mask_type = 4294967295,
        static mask_internal = 4294967295, static mask_public = 4294901760, static flag_unordered = <optimized out>, m_flags = 5, {m_value = 41539152,
          m_string = 0x279d650, m_list = 0x279d650, m_map = 0x279d650, m_sstring = {static npos = 18446744073709551615,
            m_data = 0x279d650 "Azureus 4.2.0.26:yourip4:\210]\025Ne", m_length = 15}}}}}, <No data fields>}
#2  0x00007f74940062f5 in torrent::ProtocolExtension::read_done (this=0x270ee4d) at extensions.cc:290
        blocked = <value optimized out>
#3  0x00007f749400a0dd in torrent::Handshake::read_extension (this=0x2857f40) at handshake.cc:603
        length = 174
#4  0x00007f749400b200 in torrent::Handshake::event_read (this=0x2857f40) at handshake.cc:787
No locals.
#5  0x00007f7493fb52ab in torrent::PollEPoll::perform (this=0x25675f0) at poll_epoll.cc:166
        itr = (epoll_event *) 0x2567630
        last = (epoll_event *) 0x256763c
#6  0x00000000004bb972 in core::PollManagerEPoll::poll (this=0x256e650, timeout={m_time = 890333}) at poll_manager_epoll.cc:74
No locals.
#7  0x000000000047a54b in main (argc=<value optimized out>, argv=0x7fffcfa835f8) at main.cc:321
        firstArg = <value optimized out>
        e = <value optimized out>

Oh, it's still in the handshake! Of course...

OK, please try editing the two occurences of this message in libtorrent/src/download/download_main.cc and change storage_error to communication_error. That should do it.

works perfect now! Thx a lot!

Using trunk rev 1100 with applicable DHT patches. Previously compiled libtorrent/rtorrent with ./configure LDFLAGS=-rdynamic. Also compiled curl-7.19.7 (w/o using LDFLAGS option).

Now I can paste in a magnet link and download. However, lately I get rtorrent crashes with:

Program received signal SIGPIPE, Broken pipe.
0x2045f000 in ?? ()
(gdb) backtrace
#0  0x2045f000 in ?? ()
#1  0x201a4738 in ?? ()
Previous frame identical to this frame (corrupt stack?)

Has happened three times in two days, all with same addresses.

Q1) Does the fact that no symbol info is given mean that the fault occurred outside libtorrent/rtorrent? Q2) Any ideas on how I can get a better trace?

Most probably not a bug. Found the following in  xchat-discuss@nl.linux.org mailing list:

gdb will report a received signal even if it's being ignored by the application.

You can then simply type "cont" into gdb to continue execution.

Yet another piece of gdb info to overcome above:

By default, gdb captures SIGPIPE of a process and pauses it. However, some program ignores SIGPIPE. So, the default behaviour of gdb is not desired when debugging those program. To avoid gdb stopping in SIGPIPE, use the folloing command in gdb: handle SIGPIPE nostop noprint pass

This way rtorrent execution is not impacted by SIGPIPE signals when run within gdb.

Replying to Jimmy:

Using trunk rev 1100 with applicable DHT patches. Previously compiled libtorrent/rtorrent with ./configure LDFLAGS=-rdynamic. Also compiled curl-7.19.7 (w/o using LDFLAGS option). Now I can paste in a magnet link and download. However, lately I get rtorrent crashes with: {{{ Program received signal SIGPIPE, Broken pipe. 0x2045f000 in ?? () (gdb) backtrace #0 0x2045f000 in ?? () #1 0x201a4738 in ?? () Previous frame identical to this frame (corrupt stack?) }}} Has happened three times in two days, all with same addresses. Q1) Does the fact that no symbol info is given mean that the fault occurred outside libtorrent/rtorrent? Q2) Any ideas on how I can get a better trace?

Add  http://ovh.ttdpatch.net/~jdrexler/rt/trace_internal_error.diff

I've successfully followed the instructions and tried a trackerless .torrent-less download! Thanks guys!

BTW what are the plans to incorporate this feature?

Why don't you put all diff files in one file to make it easier to patch?

@josef

little bit OT:

show_idle_times.diff is causing the following error when I want to start rtorrent. rtorrent crashes before even starting:

rtorrent@cx00:~$ gdb /usr/bin/rtorrent
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-slackware-linux"...
(no debugging symbols found)
(gdb) run
Starting program: /usr/bin/rtorrent 
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
rtorrent: initialize_commands() static command array size mismatch.

Program exited with code 0377.

Replying to anonymous:

rtorrent: initialize_commands() static command array size mismatch.

Thanks, I forgot to increase COMMAND_PEER_SLOTS_SIZE in rtorrent/src/command_helpers.h. Fixed.

Replying to anonymous:

Why don't you put all diff files in one file to make it easier to patch?

Because the dht-pex-static.diff is useful even if you don't apply the magnet patch, and it would make the magnet patch hard to review if it was a mix of both patches.

Besides, it's not more difficult to run the patch command twice, than to run it once. Deal with it.

Somebody can summarize the procedure for the support of magnet links in rtorrent please ?

Just read comment #4, it's still the same.

A few minutes after adding a magnet link, rtorrent segfaults with the following backtrace:

#0  0x0f829f88 in strlen () from /lib/libc.so.6
No symbol table info available.
#1  0x0fdb0434 in torrent::ProtocolExtension::generate_toggle_message (
    t=<value optimized out>, on=<value optimized out>) at extensions.cc:228
No locals.
#2  0x0fdbcc84 in torrent::PeerConnectionBase::send_pex_message (
    this=0x1016c398) at peer_connection_base.cc:846
No locals.
#3  0x0fdc0864 in torrent::PeerConnection<(torrent::Download::ConnectionType)0>::fill_write_buffer (this=0x1016c398) at peer_connection_leech.cc:552
        old_end = (uint8_t *) 0x10172f08 ""
        haveQueue = <value optimized out>
#4  0x0fdc2ce8 in torrent::PeerConnection<(torrent::Download::ConnectionType)0>::event_write (this=0x1016c398) at peer_connection_leech.cc:581
No locals.
#5  0x0fd4e6d4 in torrent::PollEPoll::perform (this=0x1013d9a0)
    at poll_epoll.cc:169
        itr = (epoll_event *) 0x1013d9e8
        last = (epoll_event *) 0x1013dc88
#6  0x10090f3c in core::PollManagerEPoll::poll (this=0x101366b8, timeout=
      {m_time = 1144279137054097414}) at poll_manager_epoll.cc:74
No locals.
#7  0x10047edc in main (argc=1, argv=0x7ffa9054) at main.cc:321
        firstArg = <value optimized out>
        e = <value optimized out>

Thanks, looks like I was using the wrong array, this should fix it:

Index: libtorrent/src/protocol/extensions.cc
===================================================================
--- libtorrent/src/protocol/extensions.cc       (revision 1380)
+++ libtorrent/src/protocol/extensions.cc       (working copy)
@@ -225,7 +225,7 @@
   // TODO: Check if we're accepting this message type?
 
   // Manually create bencoded map { "m" => { message_keys[t] => on ? t : 0 } }
-  return build_bencode(32, "d1:md%zu:%si%deee", strlen(ext_pex_key_names[message_keys[t]].key), ext_pex_key_names[message_keys[t]].key, on 
? t : 0);
+  return build_bencode(32, "d1:md%zu:%si%deee", strlen(ext_handshake_key_names[message_keys[t]].key) - 3, ext_handshake_key_names[message_k
eys[t]].key + 3, on ? t : 0);
 }
 
 DataBuffer

I've updated the dht-pex-static.diff too.

Everything working like a charm but show_idle_times.diff does not apply if you apply all other patches.

Replying to anonymous:

Everything working like a charm but show_idle_times.diff does not apply if you apply all other patches.

That not really the right ticket, but both show_idle_times.diff and bad_peer_handling.diff make the same change to rtorrent/src/command_helpers.h, it's not a problem to just ignore the error you get. Otherwise it applies just fine.

I have a problem with patching file : patch -p0 < dht-pex-static_map.diff

patching file rtorrent/src/core/view.cc patching file libtorrent/src/dht/dht_tracker.h patching file libtorrent/src/dht/dht_bucket.cc patching file libtorrent/src/dht/dht_bucket.h patching file libtorrent/src/dht/dht_router.cc patching file libtorrent/src/dht/dht_router.h patching file libtorrent/src/dht/dht_transaction.cc patching file libtorrent/src/dht/dht_server.cc patching file libtorrent/src/dht/dht_transaction.h patching file libtorrent/src/dht/dht_server.h patching file libtorrent/src/dht/dht_tracker.cc patching file libtorrent/src/net/address_list.cc patching file libtorrent/src/net/address_list.h patching file libtorrent/src/tracker/tracker_dht.h patching file libtorrent/src/tracker/tracker_dht.cc patching file libtorrent/src/torrent/object.h patching file libtorrent/src/torrent/object_stream.cc patching file libtorrent/src/torrent/object_stream.h patching file libtorrent/src/torrent/static_map.h patching file libtorrent/src/torrent/object.cc patching file libtorrent/src/torrent/hash_string.h patching file libtorrent/src/torrent/simple_string.h patching file libtorrent/src/torrent/static_map.cc patching file libtorrent/src/torrent/Makefile.am Hunk #1 FAILED at 41. Hunk #2 FAILED at 77. 2 out of 2 hunks FAILED -- saving rejects to file libtorrent/src/torrent/Makefile.am.rej patching file libtorrent/src/protocol/extensions.cc patching file libtorrent/src/protocol/extensions.h patching file libtorrent/src/download/download_constructor.cc

Can we get a update for 0.8.6? dht-pex-static_map no longer patches properly

I'm very noob in both torrent and rtorrent. Is there a stable version that works with TPB right now? I have 0.8.5 and it doesn't work.

You can compile rtorrent with the patches for magnet links by following  this tutorial.

Changed 3 weeks ago by anonymous

Can we get a update for 0.8.6? dht-pex-static_map no longer patches properly

Changed 3 hours ago by anonymous
Changed 3 weeks ago by anonymous
Can we get a update for 0.8.6? dht-pex-static_map no longer patches properly

If you read the tutorial all the way through, you will see the section under heading 8 explaining that 0.8.6 required the addition of  this patch. I followed the instructions, and have a working rTorrent 0.8.6 install with magnet support.

Firefox add-on magnet: link handler that creates "torrent" files containing the magnet link. See post 5.

Replying to josef:

I've created a firefox add-on that handles magnet: links and creates the file spec'd in post 5 above. I'll try and attach it here for anyone that would like to try it. Ultimately I'd like to add XMLRPC handling as well, but this was a quick and dirty hack to get the framework going.

i've applied patches from tutorial, manual loading works ok, but rpc load_* doesn't handle magnet links. is there any solution for this?

Replying to kryojenik:

Replying to josef: I've created a firefox add-on that handles magnet: links and creates the file spec'd in post 5 above. I'll try and attach it here for anyone that would like to try it. Ultimately I'd like to add XMLRPC handling as well, but this was a quick and dirty hack to get the framework going.

Insert into where ? ~/.mozilla/%profile/extensions?

Replying to anonymous:

Insert into where ? ~/.mozilla/%profile/extensions?

Just open the file from within FF. (That is, #1 download it; #2 ctrl+o to open file; #3 pick the XPI.) At least, that worked for me. :)

Replying to anonymous:

Replying to anonymous:

Insert into where ? ~/.mozilla/%profile/extensions?

Just open the file from within FF. (That is, #1 download it; #2 ctrl+o to open file; #3 pick the XPI.) At least, that worked for me. :)

You could also drag and drop it on to Firefox or install it from the add-ons site.

 https://addons.mozilla.org/en-US/firefox/addon/59335

ovh.ttdpatch.net is down. Does anyone have an alternate location?

Replying to anonymous:

i've applied patches from tutorial, manual loading works ok, but rpc load_* doesn't handle magnet links. is there any solution for this?

Apparently I've never tested this... but I've fixed it now, and updated the patches for SVN rev 1122/1123. See ticket #2052 if rev 1123 crashes on you.

 http://ovh.ttdpatch.net/~jdrexler/rt/experimental/dht-pex-static_map.diff
 http://ovh.ttdpatch.net/~jdrexler/rt/experimental/magnet-uri.diff

Replying to anonymous:

Replying to anonymous:

i've applied patches from tutorial, manual loading works ok, but rpc load_* doesn't handle magnet links. is there any solution for this?

Apparently I've never tested this... but I've fixed it now, and updated the patches for SVN rev 1122/1123. See ticket #2052 if rev 1123 crashes on you.  http://ovh.ttdpatch.net/~jdrexler/rt/experimental/dht-pex-static_map.diff
 http://ovh.ttdpatch.net/~jdrexler/rt/experimental/magnet-uri.diff

I applied these new patches but then started to get crashes with a "Peer-supplied metadata size mismatch" error as reported Mr. G in post number 64.

After reading post number 73 I noted that the file libtorrent/src/download/download_main.cc has reverted back to using "storage_error" rather than "communication_error". Changing back to using "communication_error" seems to have stoped these crashes.

Whoops, fixed again.

Replying to josef:

Whoops, fixed again.

Hmm, seems like svn 1126 and current versions of dht- and magnet-patches are not compatible. Running patch for magnet gives: patching file rtorrent/src/core/download_factory.cc Hunk #1 succeeded at 70 (offset 1 line). Hunk #2 succeeded at 140 (offset 1 line). Hunk #3 FAILED at 191. Hunk #4 succeeded at 274 (offset 22 lines). 1 out of 4 hunks FAILED

/Anders

Using latest SVN:

dht-pex-static_map.diff

patching file libtorrent/src/torrent/object.h Hunk #2 FAILED at 83. Hunk #3 FAILED at 97. Hunk #4 succeeded at 126 with fuzz 2 (offset 5 lines). Hunk #5 FAILED at 135. Hunk #6 FAILED at 202. Hunk #7 FAILED at 213. Hunk #8 FAILED at 224.

patching file libtorrent/src/torrent/object.cc Hunk #1 FAILED at 195.

magnet-uri.diff

patching file rtorrent/src/core/download_factory.cc Hunk #1 succeeded at 70 (offset 1 line). Hunk #2 succeeded at 140 (offset 1 line). Hunk #3 FAILED at 190. Hunk #4 succeeded at 264 (offset 22 lines). 1 out of 4 hunks FAILED -- saving rejects to file rtorrent/src/core/download_factory.cc.rej

patching file libtorrent/src/download/download_info.h Hunk #1 succeeded at 77 (offset 1 line). Hunk #2 FAILED at 87. Hunk #3 succeeded at 120 (offset 3 lines). Hunk #4 succeeded at 141 (offset 3 lines). Hunk #5 succeeded at 177 (offset 5 lines). Hunk #6 succeeded at 189 with fuzz 2 (offset 5 lines).

object-sstr.diff:

patching file libtorrent/src/torrent/object.cc Hunk #1 FAILED at 44. Hunk #2 succeeded at 151 (offset 8 lines).

Seems rak purposly fucks with the code the patches work on.Instead of adapting the patches

I've contacted Josef a few days ago.Still no word from him about the object_str patches Anyone?

Yeah, I'm waiting for the code to stabilize before updating the patch. No point in making new patches every day while rak is making heavy changes.

Itn't that kinda what the whole point of patching a svn repository about... Code changes > Change patch to reflect it. Code changes again > Change patch again to reflect it. He could continue working on the same portions for weeks....

Then you're welcome to update my patch every day and attach it here.

I'm afraid I do have better things to do occasionally.

It's not like you lose anything of importance by being behind a few revisions. You'll survive.

In the amount of characters you have wasted defending your illogical idea,you could have updated the patch to reflect the recent code changes.It is unstable development chain how on the fucking world can it be "stabilized"?

It takes substantially more time to update the patch than to type this. Try it yourself sometime and you'll realize it sooner than you might like. Your inane trolling by insisting I have some sort of obligation here also removed any kind of motivation whatsoever I had to update it this weekend.

Either you live by my schedule, or you do the work yourself. Deal with it, one way or another.

Also, *plonk*.

May I ask why the support for magnet links still need a patch? Wouldn't it be easier to put this whole thing in the svn repo?

ITT: Your not hot shit and others have already published patches to fix your patches. Protip.Dont push code publicly if you do not have the time to maintain them properly. As we can see with lib/r/torrent once devs start getting lazy the product suffers and you loose your support. TL;DR YOUR NOT HOT SHIT

Replying to anonymous:

ITT: Your not hot shit and others have already published patches to fix your patches. Protip.Dont push code publicly if you do not have the time to maintain them properly. As we can see with lib/r/torrent once devs start getting lazy the product suffers and you loose your support. TL;DR YOUR NOT HOT SHIT

Are you lazy stupid masturbater?

If anyone's unhappy with rTorrent, patches and what not: learn C++ and publish your own patches/rTorrent fork, or just go play elsewhere.

Don't put out software that A.You cannot keep track of B.You have no interest in after it becomes prevalent C.It is your life work is only in said program and you unable to release it to another developer who will actively manage it ten fold at what you currently develop it. D.You have no interest in it unless you are paid rent for a few months to add a few lines of code.

LOL

Not happy with rTorrent? Fork it. Or shut up.

Not happy with Josef's patches? Maintain them. Or shut up.

masturbatio is important

Hello, to my knowledge svn 1123 was the latest rev Josef's patches worked upon. So, not to fill this thread with meaningless BS back and forth (instead of thanking both rakshasa and Josef), is there a way to fetch a particular svn-rel? Or, perhaps someone has it stored?

/Anders

svn co -r 1123 svn://rakshasa.no/libtorrent/trunk

Replying to rakshasa:

{{{ svn co -r 1123  svn://rakshasa.no/libtorrent/trunk }}}

Splendid rakshasa! I also tried patches from Josef on 1123 - still works.

So, those of you that have complained, now you have the tool for getting a working rtorrent with magnet capabilities. Perhaps you will find the time to thank the designers? I know I have - thank you rakshasa and Josef!

/Anders