rakshasa / rtorrent Goto Github PK

On sparc64, rtorrent immediately crashes when starting (bus error probably caused by unaligned memory access).

This is the gdb backtrace from a Sun-Fire-V240 running OpenBSD -current:

---8<---

GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc64-unknown-openbsd5.1"...
(gdb) run
Starting program: /usr/local/bin/rtorrent

Program received signal SIGBUS, Bus error.
0x0000000000127dd4 in torrent::Object::type (this=0x94b53b) at object.h:136
136 type_type type() const { return (type_type)(m_flags & mask_type); }
(gdb) bt
#0 0x0000000000127dd4 in torrent::Object::type (this=0x94b53b) at object.h:136
#1 0x000000000012c7fc in torrent::Object::clear (this=0x94b53b) at object.h:394
#2 0x000000020a1ccdb4 in torrent::Object::operator= (this=0x94b53b, src=@0xfffffffffffe1df8) at object.cc:196
#3 0x00000000001396d0 in initialize_command_local () at command_local.cc:401
#4 0x000000000013069c in initialize_commands () at command_helpers.cc:61
#5 0x0000000000121df0 in main (argc=1, argv=0xfffffffffffe25e8) at main.cc:192

(gdb) bt full
#0 0x0000000000127dd4 in torrent::Object::type (this=0x94b53b) at object.h:136
#1 0x000000000012c7fc in torrent::Object::clear (this=0x94b53b) at object.h:394
#2 0x000000020a1ccdb4 in torrent::Object::operator= (this=0x94b53b, src=@0xfffffffffffe1df8) at object.cc:196
#3 0x00000000001396d0 in initialize_command_local () at command_local.cc:401

chunkManager = (torrent::ChunkManager *) 0x20ff8cc00
fileManager = (torrent::FileManager *) 0x2045c82c0
dList = (core::DownloadList *) 0x20537ebb0
dStore = (core::DownloadStore *) 0x20cd76b80

#4 0x000000000013069c in initialize_commands () at command_helpers.cc:61
#5 0x0000000000121df0 in main (argc=1, argv=0xfffffffffffe25e8) at main.cc:192

firstArg = 9746192
e = (std::exception &) @0x207a0c000: {_vptr.exception = 0xd3000000000}

---8<---

The latest git version of rtorrent crashes during a "print" call via XMLRPC:
terminate called after throwing an instance of 'torrent::internal_error'
what(): Manager::push_log(...): Cannot call this function from other threads than 'main'.

I would ask for the addition of new commands
to extract more information about the tracker with rtorrent

1. Next time update
2. status tracker
3. last update
   Please see this forum topic.
   http://forums.rutorrent.org/index.php?topic=1327.0

It would be great if this information were to be drawn by rutorrent

Compiling against most recent github versions of libtorrent and rtorrent.

g++ -DHAVE_CONFIG_H -I. -I../.. -I. -I./.. -I../.. -g -O2 -DNDEBUG -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include -MT window_download_statusbar.o -MD -MP -MF .deps/window_download_statusbar.Tpo -c -o window_download_statusbar.o window_download_statusbar.cc
window_download_statusbar.cc: In member function 'virtual void display::WindowDownloadStatusbar::redraw()':
window_download_statusbar.cc:94:49: error: 'class core::Download::download_type' has no member named 'time_next_connection'

I've tried to correct the error, but I don't know enough C++.

There appear to be quite a few changes/additions of the .rc commands and the new format. Yet, I can't really find any documentation on all of the new commands or just a reference list that shows the command and what it does. The latter would be a good place to start, and if a command needs better explanation, that can eventually be expanded upon.

If a file is marked as “off”, I really don't want its 0-byte stub in the directory, making it harder to see at a glance which is actually a file and which is not.

Suggestions:

1. Stubs should be only generated when at least 1 block has been downloaded for a file.
2. Blocks downloaded for a file marked “off” should be discarded. So if a single block covers the end of one file and the start of another file marked “off”, the second half would be discarded (and have to be redownloaded if the user does want those files later on).
3. Marking a file as “off” and pressing a certain keybind (for “cleanup”) should, after confirmation, delete the no longer wanted files.

Sorry about the format of this bug report, it's kind of vague because I don't have much detail to give. This seems to be an isolated occurrence, but it seems serious enough to report in case others are having similar problems.

Quick baseline:
rtorrent/libtor svn1272, Ubuntu 11.04, 16GB of RAM

Description:
On my machine with 16GB of RAM, rtorrent is the only thing running and it somehow got itself into a spot where it was using 50.1% (8.0001GB) of resident memory (as shown by top). At that point it started spitting out fork errors (ERR_NOMEM) every time it tried to spawn a scheduled process (which happens a few times a minute). I didn't notice this until 6 hours later, at which point I had to kill and restart rtorrent to free the RAM. In that entire time, rtorrent continued with its data transfers at ~2MB/s up&down, but all other scheduled activity stopped due to fork errors. Obviously the forks were failing because each child requires exactly as much memory as the parent, but...

Questions:

1. why would rtorrent require 8GB in the first place? I could understand if there were high speeds and thousands of buffers involved, but transfer speeds were slow--at only 2MB/s up and down--with 17 active torrents. If it makes a difference, the total size of the active torrents was about 500GB, the size of ALL seeding torrents was over a terabyte, and the active torrents included 4 slow downloads totalling 100GB, and downloading at a total of 2MB/s. rtorrent reported memory usage of ~150MB, so there must have been almost 8GB of memmapped files. I'm afraid that running memtest slipped my mind until after I killed/restarted rtorrent, but 8GB seems extremely high no matter what it was trying to do. I lowered the bufsize to 256k, maxOpenFiles to 4, and stopped all torrents except the downloads, but there was no change in memory usage so I just shut down rtorrent and restarted.

2. Has rtorrent always forked the scheduled processes this way? Because if so, then rtorrent could never have used more than half the available memory, which seems to be a huge waste (and it also should have caused problems for me and many other people). And, it also means that there could only be one forked process running at a time, or the memory problem goes up exponentially. Either way, would it be possible to fix this by running just a small controller as the main program, which would delegate all the memmaps and scheduled processes into separately-forked child processes? This way the main program and all of its forks would be tiny, although I assume it could take a fair amount of rewriting to structure it this way (I haven't looked at the code yet).

3. Although I didn't get to run memstat, is there anything that seems likely to be causing this? Could the memmapped regions be leaking memory instead of getting freed, or any other likely explanation? I've watched the resident memory, and in normal use the RAM usage occasionally jumps up to ~2GB when I'm downloading above 50MB/s (400Mbps)...but within seconds it flushes the data and the RAM usage returns to just a couple hundred MB. This time it seems to have kept rising until it hit 8GB, at which point it couldn't rise any further or apparently even drop, and it just got stuck until I shut down rtorrent.

4. ...Or is it maybe something that's just configured wrong with my setup, and not rtorrent at all?

Again, sorry for the report with lots of talk and few facts, but I'm hoping this description is enough to give an idea of what happened.

While starting torrents, I get the following output and rtorrent crashes:

0 rtorrent(_Z13handle_sigbusiP7siginfoPv+0x41) [0x444af1]
1 /lib64/libc.so.6(+0x362c0) [0x7f267e9b62c0]
2 /lib64/libc.so.6(+0x8a9a3) [0x7f267ea0a9a3]
3 /usr/lib64/libtorrent.so.14(+0x80140) [0x7f267fcd0140]
4 /usr/lib64/libtorrent.so.14(+0xd60ed) [0x7f267fd260ed]
5 /usr/lib64/libtorrent.so.14(+0xd61dd) [0x7f267fd261dd]
6 /usr/lib64/libtorrent.so.14(+0xe0fc6) [0x7f267fd30fc6]
7 /usr/lib64/libtorrent.so.14(_ZN7torrent9PollEPoll7performEv+0xd8) [0x7f267fc923b8]
8 rtorrent() [0x51e6c4]
9 rtorrent() [0x4497b4]
10 /lib64/libc.so.6(__libc_start_main+0xed) [0x7f267e9a14cd]
11 rtorrent() [0x4437e9]

Error: Success
Signal code '2': Non-existent physical address.
Fault address: 0x7f267d430000.

The fault address is not part of any chunk.

I used 0.8.3 and 0.8.4 for a very long time without issues.

Additional info:
libtorrent 0.13.0
libsigc++ 2.2.3
glibc 2.14.1
kernel 2.6.39.1

Need more info?

See http://libtorrent.rakshasa.no/ticket/2115 for details.

In gdb wee may to see:

(gdb) s
rak::cacheline_allocator<rak::priority_item*>::alloc_size (size=8)
    at ../rak/allocators.h:79
79          pointer ptr = NULL;
(gdb) n
80          int __UNUSED result = posix_memalign((void**)&ptr, LT_SMP_CACHE_BYTES, size);
(gdb) n
82          return ptr;
(gdb) p result
$6 = 22
(gdb) p ptr
$7 = (rak::priority_item **) 0x0
(gdb) p size
$8 = 8
(gdb) p LT_SMP_CACHE_BYTES
$9 = 1
(gdb) bt
#0  rak::cacheline_allocator<rak::priority_item*>::alloc_size (size=8)
    at ../rak/allocators.h:82
#1  0x00002aaaaaf6c5e7 in rak::cacheline_allocator<rak::priority_item*>::allocate (this=0x2aaaab2ca680, num=1, hint=0x0) at ../rak/allocators.h:76
#2  0x00002aaaaaf6c60f in std::_Vector_base<rak::priority_item*, rak::cacheline_allocator<rak::priority_item*> >::_M_allocate (this=0x2aaaab2ca680, __n=1)
    at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_vector.h:127
#3  0x00002aaaaaf6c79c in std::vector<rak::priority_item*, rak::cacheline_allocator<rak::priority_item*> >::_M_insert_aux (this=0x2aaaab2ca680, __position=Cannot access memory at address 0x0
)
    at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/vector.tcc:275
#4  0x00002aaaaaf6c9f0 in std::vector<rak::priority_item*, rak::cacheline_allocator<rak::priority_item*> >::push_back (this=0x2aaaab2ca680,
    __x=@0x7fffffffe290)
    at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_vector.h:610
#5  0x00002aaaaaf6ca10 in rak::priority_queue<rak::priority_item*, rak::priority_compare, std::equal_to<rak::priority_item*>, rak::cacheline_allocator<rak::priority_item*> >::push (this=0x2aaaab2ca680, value=@0x7fffffffe290)
    at ../rak/priority_queue.h:77
#6  0x00002aaaaaf6cf8e in rak::priority_queue_insert (queue=0x2aaaab2ca680,
    item=0x820d98, t=...) at ../rak/priority_queue_default.h:116
#7  0x00002aaaaaf69571 in torrent::Manager::Manager (this=0x820d20)
    at manager.cc:89
#8  0x00002aaaaaf8aa54 in torrent::initialize (poll=0x8124b0) at torrent.cc:104
#9  0x0000000000412aab in main (argc=1, argv=0x7fffffffe998) at main.cc:198

e.q. LT_SMP_CACHE_BYTES is setted to 1, this is a invalid value.

And yes, in config.h (after configure) we may to see:

#define LT_SMP_CACHE_BYTES 1

For avoid this you must remove the superfluous comma in files libtorrent/scripts/common.m4 and rtorrent/scripts/common.m4, e.q. replace lines

AC_DEFINE(LT_SMP_CACHE_BYTES, 128, Largest L1 cache size we know of, should work on all archs.)

to

AC_DEFINE(LT_SMP_CACHE_BYTES, 128, Largest L1 cache size we know of)

and all will be OK.

Has svn access been completely disabled? I thought it was going to mirror git, but it's no longer possible to access the svn repository. I'll obviously switch to git eventually, but atm I just wanted to grab a quick patch and backport it into an older svn tag...but I can't get at svn!

svn: Can't connect to host 'rakshasa.no': Connection refused

It realization is bad, because it return binary string. Raw binary data can't be send via XMLRPC, its must be wrapped into base64 container. Or it may be passed as hex string.
Otherwise browser can't understand it, because result xml is a not valid.

I figured out that if I use a relative "directory", the file path stored in the session for a torrent is also relative, and if I use an absolute "directory", the file path stored is also absolute.

It would help a lot in the migration of files directories if the path stored in the session were by default stored relative to the "directory" setting. At first, I can not think of any drawback of the approach. What do you think? At least would be nice to have a configure switch to do it, I would use.

I will probably do a patch myself, I am just creating the ticket because I wanted some opinions on the best approach to this...
My idea is that migrating a whole torrent directory, full of complete and partial downloads is as simple as moving the directory and changing its path in .rtorrent.rc .

When I call download_list and pass it "completed" (or any argument for that matter), I get an Unsupported Target Type error. Is this a known bug with the version of rtorrent I'm using? I see a few tickets open on the web about this problem, but no further information on them.

Thanks!

Any chance of getting a 0.9.1 tag with the Clang fixes?

rTorrent 0.9.0 fails to build with clang on Mac OS X 10.7:

/Developer/usr/bin/clang++ -DHAVE_CONFIG_H -I. -I../.. -I. -I./.. -I../..  -I/opt/local/include  -pipe -O2 -arch x86_64 -DNDEBUG -I/opt/local/include/sigc++-2.0 -I/opt/local/lib/sigc++-2.0/include   -I/opt/local/include   -I/opt/local/include   -MT window_http_queue.o -MD -MP -MF .deps/window_http_queue.Tpo -c -o window_http_queue.o window_http_queue.cc
window_file_list.cc:126:19: error: variable length array of non-POD element type 'iterator' (aka 'torrent::FileListIterator')
  iterator entries[m_canvas->height() - 1];
                  ^
1 error generated.

Hi,

This issue has been reported in Debian [1], originally on rtorrent 0.8.6, but it seems to affect 0.8.9 too. I'll just quote from the original bug report:

(about 0.8.6)

Toggling peer snubbing off with * seems to leave that peer permanently
choked, even when it wakes up and starts feeding me data.

The only way I can find to bring the connection back to life is to kick
off the peer and let it reconnect.

libtorrent11 0.12.6-2, BTW.

(about 0.8.9)

As of Version: 0.8.9-2 with libtorrent14 Version: 0.12.9-3 it's still
there. (I'm running sid rather than wheezy; I figure for this purpose
that's not a problem.)

4 peers, each receiving 20 k/s, were snubbed for a second, then
immediately unsnubbed, and their rates have gone to 0 and stayed there.
If I kick them off, they reconnect and start transferring again.

Any idea what's causing this?

Cheers,

Benoît Knecht

I've got the following exception: "rtorrent: priority_queue_insert(...) called on an already queued item"

I am using FreeBSD 8.2.

The trackers in the tracker list always show S/L: 0/0.

But i can see the peers in the peer list, and also in the bottom the Peers: value is correct.

Sometimes, very rarely i do see some seeds/ leechers in the trackers list, but even then i think the value is incorrect. But mostly it is 0/0, even for dht.

I am happily surprised to see the move of your projects to github! I'm sure it'll encourage more contributions :)

However, now that we're happily on git, have you considered perhaps switching to a different branching/tagging model? Branching operations are ridiculously cheap (i.e. fast, easy, painless) on git compared to subversion as I'm sure you're aware. I think it might be nice to have some way of fetching a copy of the source that has the latest fixes applied, instead of having to wait for them until the new experimental functionality is ironed over and a new major version is released.

One method I've seen is to keep master stable while applying fixes etc. to it, and developing the next version on a separate branch such as dev. Of course this is just one way, it's really up to you. You could do it the other way around even (i.e. master is bleeding and stable is stable). My main point is that merging in patches/fixes is convenient enough that it might be possible to maintain a stable version with the latest fixes separate from experimental, perhaps yet unstable, code.

So for example, say a critical fix comes in for 0.8.9, if 0.8.9 'snapshot'/stable was the master branch, you simply merge in the fix to master and then you can merge that commit into your dev branch so that it too has the fix. Then for added benefit, you can tag the new minor version if you want.

Some references:

• Managing stable and unstable branches in Git
• Branching and Merging (look at the section merging and removing finished branches)

A nice advantage to this is that users can more or less always have a 'safe bleeding edge' by simply cloning the repo :) It might also cut down on people filing issues for things that have already been fixed but that they can't benefit from unless they track down the fix and merge it in manually. This is something I recently did with r1246 which finally did away with the sporadic crashes I was having! I wasn't even aware of that fix until I ran into it by pure chance after googling for a while. Who knows what other fixes I might be missing out on.

Again it's entirely up to you, I just figured I'd bring it up. Please don't misinterpret my comments, I am not trying to tell you how to run your own project! I'm a fan :)

Can't download a files more then 4Gb. After download finished, a hash check fails precisely on 4096Mb mark.

Neither filesystem (ext3/ext4) nor a preallocation (on/off) is not affected on this bug.

rtorrent 0.9.1/libtorrent 0.13.1, toolchain is gcc 4.4.6 + uClibc 0.9.32, MIPSEL arch.

Cross-compilation patch - http://wl500g-repo.googlecode.com/svn/trunk/packages/rtorrent/555-disable-AM_PATH_CPPUNIT-check.patch

Currently, rtorrent fails to compile on some systems because it’s missing some compiler flags.

Please add Autoconf checks for pthread, and use the appropriate compiler flags (on most systems, adding -pthread to CXXFLAGS and LDFLAGS should do the trick).

It would be really handy to be able to search/filter in certain views, like the main torrent view (for users who seed many torrents) or the files view (for torrents with many files).

This doesn't happen in 0.8.6.

Upgraded to 0.9.0 with the option check_hash = no in .rtorrent.rc . However, it still checks the torrents whenever the client is restarted.

Would be nice if rtorrent would only check upon the user's request to do so.

This well-known torrent:

http://wlstorage.net/torrent/wikileaks-insurance-20120222.tar.bz2.aes.torrent

represents an over 65 GB large file.

When loaded into rtorrent, it does not start downloading. rtorrent says:

* [CLOSED]     0.0 / 65862.4 MB Rate:   0.0 /   0.0 KB Uploaded:     0.0 MB                 [ I R: 0.00]
* Hashing:

(yes, there's nothing after the Hashing:). The status does not ever seem to change. No temporary file is created in the incomplete/ folder either.

What could this be?

When I add a new torrent and uncheck some of the files that I do not need, rtorrent still partially downloads some of them. I know that this is the limitation of bittorrent protocol and it's ok for me, but I do not want to see these files files in a destination folder because they are trash, I don't need them, and sometimes they are confusing (e.g. if their names are not very informative). Moreover, even in this case rtorrent creates a full directory structure and all the files from the torrent for no clear reason.
This may be solved by moving the parts of unneeded files to some temporary folder (ktorrent does that), or by appending all of them to a single temporary file in the destination folder (like utorrent does). Both ways have have their own advantages.
I think, if you implement this feature, many users will be very grateful to you, me for sure.

Architecture: arm (D-Link DNS-323) - NOT armel

OS: Debian lenny
Delorian:/etc/apt/sources.list.d# uname -a
Linux Delorian 2.6.12.6-arm1 #29 Wed Apr 30 10:03:59 CST 2008 armv5tejl GNU/Linux

GCC version: 4.2.4
Delorian:/etc/apt/sources.list.d# g++ -v
Using built-in specs.
Target: arm-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libssp --enable-checking=release --build=arm-linux-gnu --host=arm-linux-gnu --target=arm-linux-gnu
Thread model: posix
gcc version 4.2.4 (Debian 4.2.4-6)

Versions: all "stable" as of 2012-04-02
libtorrent: 0.12.9
xmlrpc-c 1.25.15 (svn checkout from stable branch)
rtorrent 0.8.9

Output of configure:
...
checking pkg-config is at least version 0.9.0... yes
checking for sigc... yes
checking for libcurl... yes
checking for libtorrent... yes
checking for XMLRPC-C... failed
configure: error: Could not compile XMLRPC-C test.

Error in config.log:
configure:16636: checking for XMLRPC-C
configure:16670: g++ -o conftest -g -O2 -g -DDEBUG -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/local/include -I/usr/local/include co
nftest.cpp -lncurses -lsigc-2.0 -lcurl -L/usr/local/lib -ltorrent -L/usr/local/lib -lxmlrpc_server -lxmlrpc -lxmlrpc_util -lxmlrpc_xmlparse -lxmlrpc_xm
ltok >&5
/usr/local/lib/libtorrent.so: undefined reference to __sync_add_and_fetch_4' /usr/local/lib/libtorrent.so: undefined reference to__sync_sub_and_fetch_4'
collect2: ld returned 1 exit status
configure:16670: $? = 1
configure: failed program was:
| /* confdefs.h /
| #define PACKAGE_NAME "rtorrent"
...
| #define FS_STAT_BLOCK_SIZE (m_stat.f_frsize)
| / end confdefs.h. */
| #include <xmlrpc-c/server.h>
|
| int
| main ()
| {
| xmlrpc_registry_new(NULL);
| ;
| return 0;
| }
configure:16677: result: failed
configure:16679: error: Could not compile XMLRPC-C test.

Attaching logs (if I manage to do so...)
I suspect this is a bug in this gcc version; but it is a "stable" release so I suppose it should work with the "required" compiler which is 4.2.1+

So if you cannot reproduce the problem, please ask for more info instead of closing with "worksforme". If I'm not mistaken. In the particular case of arm architecture, maybe we should figure out which libc function should be avoided in the "stable" code...

Run any command with execute.nothrow.bg and it stays in the process list forever until rTorrent is restarted. It looks like the child process is not exiting correctly.

Steps to reproduce:

Then check process list:

   29071 pts/6    Z+     0:00 [uptime] <defunct>
   29153 pts/7    S+     0:00 grep --color=auto defunct
   [shaca@mordor ~]$

This bug is reproducible on Debian 5, Debian 6, CentOS 5, Fedora 15

latest libtorrent-git and rtorrent-git at the time of posting this

https://pastee.org/vv4jd

Currently, as far as I know, when one issues a set_directory call followed by a load_start call, to essentially set the directory for the torrent about to be added, the fact that they are two separate calls opens it up to race conditions, resulting in torrents being saved to the wrong directory. Is there, or can there be in the future, a command that lets one specify a torrent and a directory destination in one self-contained call?

On the other hand, is something like this already possible by avoiding the call to load_start? For example, can I do a normal load and then use something like d.set_directory followed by a d.start call? The problem is, how would I get the hash of that torrent that was just loaded in order to issue the two subsequent calls? I just tried running a simple load and it seems the server only responds with an i4:0 and not the hash of the torrent.

Previously what I was doing was wrapping both calls into a single job within a job queue processor like resque and it works fine, but perhaps there is a simpler way of doing this. If there is no way to retrieve the hash after a load, or otherwise operate on the just-loaded torrent (in order to specify its destination directory, d.set_directory), I guess I can bencode-decode the torrent and determine the hash manually, but it'd really be nice if there were a way to do this built into rtorrent :)

When using the following event to moving out finished torrent

system.method.set_key = \
 event.download.finished, \
 move_complete, \
 "d.set_directory=/usr/home/user/f/;execute=mv,-n,$d.get_base_path=,/usr/home/user/f/"

got segmentation fault with the following gdb backtrace

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 28b01140 (LWP 100092)]
torrent::Tracker::failed_counter (this=0x0) at tracker.h:114
114       uint32_t            failed_counter() const                {return m_failed_counter; }
(gdb) info threads
 4 Thread 28ce5340 (LWP 100162)  0x28a87b7b in kevent () from /lib/libc.so.7
 3 Thread 28ce7140 (LWP 100161)  0x28a87b7b in kevent () from /lib/libc.so.7
* 2 Thread 28b01140 (LWP 100092)  torrent::Tracker::failed_counter (this=0x0) at tracker.h:114
(gdb) thread 2
[Switching to thread 2 (Thread 28b01140 (LWP 100092))]
#0 torrent::Tracker::failed_counter (this=0x0) at tracker.h:114
114       uint32_t            failed_counter() const                {return m_failed_counter; }
(gdb) bt
#0  torrent::Tracker::failed_counter (this=0x0) at tracker.h:114
#1  0x081fcdef in torrent::TrackerController::do_timeout (this=0x2a7fee80) at tracker_controller.cc:444
#2  0x081ffbc3 in std::tr1::_Mem_fn<void (torrent::TrackerController::*)()>::operator() (this=0x2a6ff3b0, __object=0x2a7fee80) at functional_iterate.h:214
#3  0x081ffb55 in std::tr1::_Bind<std::tr1::_Mem_fn<void (torrent::TrackerController::*)()> ()(torrent::TrackerController*)>::operator() (this=0x2a6ff3b0) at bind_iterate.h:45
#4  0x081ff83f in std::tr1::_Function_handler<void ()(), std::tr1::_Bind<std::tr1::_Mem_fn<void (torrent::TrackerController::*)()> ()(torrent::TrackerController*)>>::_M_invoke (__functor=@0x29bfff78) at functional_iterate.h:502
#5  0x0805bc76 in std::tr1::function<void ()()>::operator() (this=0x29bfff78) at functional_iterate.h:865
#6  0x082d5120 in torrent::thread_main::call_events (this=0x28bc7380) at thread_main.cc:79
#7  0x0825453b in torrent::thread_base::event_loop (thread=0x28bc7380) at thread_base.cc:114
#8  0x080543af in main (argc=0x1, argv=0xbfbfe790) at main.cc:872
(gdb) thread 3
[Switching to thread 3 (Thread 28ce7140 (LWP 100161))]#0  0x28a87b7b in kevent () from /lib/libc.so.7
(gdb) bt
#0  0x28a87b7b in kevent () from /lib/libc.so.7
#1  0x081f02b9 in torrent::PollKQueue::poll (this=0x28b273d0, msec=0x2711) at poll_kqueue.cc:166
#2  0x081f0791 in torrent::PollKQueue::do_poll (this=0x28b273d0, timeout_usec=0x989680, flags=0x1) at  poll_kqueue.cc:258
#3  0x082546eb in torrent::thread_base::event_loop (thread=0x28bc7700) at thread_base.cc:144
#4  0x284ce77f in pthread_getprio () from /lib/libthr.so.3
#5  0x00000000 in ?? ()
(gdb) thread 4
[Switching to thread 4 (Thread 28ce5340 (LWP 100162))]#0  0x28a87b7b in kevent () from /lib/libc.so.7
(gdb) bt
#0  0x28a87b7b in kevent () from /lib/libc.so.7
#1  0x081f02b9 in torrent::PollKQueue::poll (this=0x28b27100, msec=0x927c1) at poll_kqueue.cc:166
#2  0x081f0791 in torrent::PollKQueue::do_poll (this=0x28b27100, timeout_usec=0x23c34600, flags=0x1) at poll_kqueue.cc:258
#3  0x082546eb in torrent::thread_base::event_loop (thread=0x28b85200) at thread_base.cc:144
#4  0x284ce77f in pthread_getprio () from /lib/libthr.so.3
#5  0x00000000 in ?? ()
(gdb) c
Continuing.
Caught Segmentation fault, dumping stack:
Stack dump not enabled.

Program received signal SIGABRT, Aborted.
0x289fc6db in thr_kill () from /lib/libc.so.7
(gdb) bt
#0  0x289fc6db in thr_kill () from /lib/libc.so.7
#1  0x284d4956 in pthread_kill () from /lib/libthr.so.3
#2  0x284d23d3 in raise () from /lib/libthr.so.3
#3  0x28a9f7aa in abort () from /lib/libc.so.7
#4  0x080545e9 in do_panic (signum=0xb) at main.cc:999
#5  0x08057231 in sigc::pointer_functor1<int, void>::operator() (this=0x28b272a0, _A_a1=@0x28b272a4) at ptr_fun.h:111
#6  0x080571f9 in sigc::adaptor_functor<sigc::pointer_functor1<int, void> >::operator()<int&> (this=0x28b2729c,   _A_arg1=@0x28b272a4) at adaptor_trait.h:84
#7  0x080571c6 in sigc::bind_functor<-1, sigc::pointer_functor1<int, void>, int, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>::operator() (this=0x28b27298) at bind.h:1110
#8  0x08057182 in sigc::internal::slot_call0<sigc::bind_functor<-1, sigc::pointer_functor1<int, void>, int, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>, void>::call_it (rep=0x28b27280) at slot.h:103
#9  0x080c7fe6 in sigc::slot0<void>::operator() (this=0x845bec4) at slot.h:440
#10 0x080c9fea in SignalHandler::caught (signum=0xb) at signal_handler.cc:99
#11 <signal handler called>
#12 torrent::Tracker::failed_counter (this=0x0) at tracker.h:114
#13 0x081fcdef in torrent::TrackerController::do_timeout (this=0x2a7fee80) at tracker_controller.cc:444
#14 0x081ffbc3 in std::tr1::_Mem_fn<void (torrent::TrackerController::*)()>::operator() (this=0x2a6ff3b0, __object=0x2a7fee80) at functional_iterate.h:214
#15 0x081ffb55 in std::tr1::_Bind<std::tr1::_Mem_fn<void (torrent::TrackerController::*)()> ()(torrent::TrackerController*)>::operator() (this=0x2a6ff3b0) at bind_iterate.h:45
#16 0x081ff83f in std::tr1::_Function_handler<void ()(), std::tr1::_Bind<std::tr1::_Mem_fn<void (torrent::TrackerController::*)()> ()(torrent::TrackerController*)>>::_M_invoke (__functor=@0x29bfff78) at functional_iterate.h:502
#17 0x0805bc76 in std::tr1::function<void ()()>::operator() (this=0x29bfff78) at functional_iterate.h:865
#18 0x082d5120 in torrent::thread_main::call_events (this=0x28bc7380) at thread_main.cc:79
#19 0x0825453b in torrent::thread_base::event_loop (thread=0x28bc7380) at thread_base.cc:114
#20 0x080543af in main (argc=0x1, argv=0xbfbfe790) at main.cc:872

If I remove mv event everything is fine. Is my event logic bad?

The system is a FreeBSD 8.2 32bit and executable compiled with clang 3.0.

There's an XML/RPC command to upload a .torrent file to the rTorrent server - load.raw.

A command that would download the .torrent file back would be quite useful.

Cannot kill rtorrent process normally using INT signal on Debian Squeeze. I'm using the latest git version of rtorrent.

rTorrent 0.8.6/0.12.6, Debian Squeeze x86

This 4478.4MB torrent will appear as 382.4MB:
http://cdimage.debian.org/debian-cd/6.0.3/amd64/bt-dvd/debian-6.0.3-amd64-DVD-1.iso.torrent:

$ XMLRPC_TRACE_XML=1 xmlrpc localhost d.get_size_bytes 47913E5A2559C95211E761834010965D8AD6FF29
XML-RPC CALL:

\r\n
d.get_size_bytes\r\n
\r\n

XML-RPC RESPONSE:

\r\n
\r\n

Result:

Integer: 400990208 (-> 382.4MB)

I've emailed the lead dev about this issue (and also opened bugs on the old trac based system) but i figured since development has moved to github i'd report the bug here.

I'm no programmer or debugger so i'm not quite sure how to figure out why this happenes but it seems to be related to changed in how XMLRPC works on the later versions. I can run 0.8.6 with xmlrpc without issue, but anything newer will crash.

It's important to note that if i run them WITHOUT xmlrpc-c they function fine.

i've tried to do several backtraces with various options

http://pastie.org/3717823
http://pastie.org/3673636
http://pastie.org/3673674

when i run gdb

with
handle SIGUSR1 nostop noprint
handle SIGPIPE nostop noprint

i get this:

(gdb) run
Starting program: /usr/local/bin/rtorrent
warning: Lowest section in /usr/lib/libpthread.so.1 is .dynamic at 00000074
warning: Lowest section in /usr/lib/libdl.so.1 is .dynamic at 00000074
[New LWP 1]
[New LWP 2]
rtorrent: Listener port received an error event.

Program exited with code 0377.
(gdb) thread apply all bt full
No registers.
(gdb) bt full
No stack.

If anyone has any suggestions, please let me know. I would even be willing to set up a system with remote ssh access for any dev who thinks they can figure this out.

If some files in a torrent are marked as “off”, these should not factor into the completion percentage. So if I have half the files (size-wise) disabled, the torrent should be displaying 100% when it's in reality at 50%. Right now, the torrent just stops at 50%.

Of course, this should be a toggleable feature.

Would it be possible to provide a daemon version of rtorrent that doesn't have a UI and just sits there waiting for XML RPC requests? At the moment, I need to mess around with screen - if i just do rtorrent & disown, XML RPCs hang for some reason.

It doesn't even need to background itself, since start-stop-daemon can handle this pretty easily. (Actually, if you did make it background itself by using fork(), you would also need to create a pidfile somewhere so start-stop-daemon can get at the new pid).

It would be really useful for scripting things with torrents. transmission-daemon is the only other client that comes close in this regard, but their RPC client doesn't output machine-parseable data, and for some reason it's not connecting properly for my setup (but rtorrent does). Also they don't support the http_cacert options which is pretty important for what I want to do (encrypted backup over bittorrent).

Rtorrent Crashes when some downloads complete.

It could be random. A 350MB file or 700MB or 1GB+

This is what is left on my console:

Caught Segmentation fault, dumping stack:
0 rtorrent() [0x413f10]
1 rtorrent() [0x4444e7]
2 /lib/libc.so.6(+0x33af0) [0x7f092adcdaf0]
3 /usr/local/lib/libtorrent.so.14(_ZN7torrent17TrackerController10do_timeoutEv+0x132) [0x7f092c3575e2]
4 /usr/local/lib/libtorrent.so.14(_ZN7torrent7performEv+0x119) [0x7f092c354809]
5 rtorrent() [0x4a69b2]
6 rtorrent() [0x413a1a]
7 /lib/libc.so.6(__libc_start_main+0xfd) [0x7f092adb8c4d]
8 rtorrent() [0x40fe69]

I have this line scheduler.max_active.set = 5 and/or scheduler.max_active.set = 5
When I have 5 active torrents, I am adding new torrents and they are stopped. Next I pauses/stopping one of the active and the rest of latest added now starting, and then I have for example 8 active torrents with line above.

My rTorrent version is 0.8.9

When compiling command_tracker.cc, it fails with the error "error: ‘sscanf’ is not a member of ‘std’". I read into this and am no expert, but I added #include to command_tracker.cc and it compiled fine.

g++ -g -O2 -g -DDEBUG -I/usr/local/include/sigc++-2.0 -I/usr/local/lib/sigc++-2.0/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -o rtorrent main.o libsub_root.a ui/libsub_ui.a core/libsub_core.a display/libsub_display.a input/libsub_input.a rpc/libsub_rpc.a utils/libsub_utils.a -lncursesw -L/usr/local/lib /usr/local/lib/libcurl.so -L/usr/kerberos/lib -lldap -lrt -lssl /usr/local/lib/libtorrent.so -lcrypto -ldl -lz /usr/local/lib/libsigc-2.0.so -lxmlrpc_server -lxmlrpc -lxmlrpc_util -lxmlrpc_xmlparse -lxmlrpc_xmltok -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib
libsub_root.a(thread_base.o): In function thread_queue_hack::lock()': /root/rtorrent-0.9.0/src/thread_base.cc:68: undefined reference to__sync_bool_compare_and_swap_4'
/root/rtorrent-0.9.0/src/thread_base.cc:68: undefined reference to __sync_bool_compare_and_swap_4' libsub_root.a(thread_base.o): In functionthread_queue_hack::push_back(void ()(ThreadBase))':
/root/rtorrent-0.9.0/src/thread_base.cc:84: undefined reference to __sync_bool_compare_and_swap_4' /root/rtorrent-0.9.0/src/thread_base.cc:85: undefined reference to__sync_bool_compare_and_swap_4'
libsub_root.a(thread_worker.o): In function ThreadWorker::set_scgi(rpc::SCgi*)': /root/rtorrent-0.9.0/src/thread_worker.cc:72: undefined reference to__sync_bool_compare_and_swap_4'
collect2: ld returned 1 exit status
make[3]: *** [rtorrent] Error 1
make[3]: Leaving directory /root/rtorrent-0.9.0/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory/root/rtorrent-0.9.0/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/rtorrent-0.9.0'
make: *** [all] Error 2
[root@ns1 ~]#

I don't understand about this error issue, any help?

Hello,

I'd like to request a feature that allows users to search for a specific torrent, e.g. using the widely known / key for searching, I imagine it would be rather easy to implement. Not sure, though.

I seed on thousands of general public torrents, and I can never find the one I'm looking for. For example, I would love if I could hit the / key, type a few letters and it searches the torrents in the current buffer for a torrent with that name.

Sincerely hoping that this request wont be in vein.
Thanks in advance.

Enhancement. Would be great to sort files and folders within torrent before display or after insert in rtorrent. Instead of displaying

a/files1
c/files1
a/files2
b/files1
a/files3

display as

a/files1
a/files2
a/files3
b/files1
c/files1

Unfortunately some torrent does not have sorted content and hard to select needed files.

Most of us don't use our Internet at night hence don't care about whether upload affects surfing experience or not. I would like to have a "night mode" so that during certain time period of each day, rtorrent will automatically use a different set of throttling parameters. This feature will benefit everybody.

Latest git revision on FreeBSD 8.2. When download is finished rtorrent stop the torrent. No schedule for this. What interesting that it writes as stopped but I can press ctrl-d for "real" stop and ctrl-d again for remove torrent from list.

Hi there,

I'm running in to problems with rTorrent and ruTorrent.
When I add a Magnet link to my rTorrent through ruTorrent rTorrent crashes.

I'm running rTorrent 0.9.0 in a screen session and ruTorrent 0.13.0 on apache 2.2.14.

Could someone please tell me what's going wrong here?

Here below is the stacktrace that I get:
Caught Segmentation fault, dumping stack:
0 rtorrent() [0x413f20]
1 rtorrent() [0x4444f7]
2 /lib/libc.so.6(+0x33af0) [0x7feaccf65af0]
3 /usr/local/lib/libtorrent.so.14(+0x49514) [0x7feacea8f514]
4 /usr/local/lib/libtorrent.so.14(+0x9e192) [0x7feaceae4192]
5 /usr/local/lib/libtorrent.so.14(+0x74a72) [0x7feaceabaa72]
6 /usr/local/lib/libtorrent.so.14(+0x74dc9) [0x7feaceabadc9]
7 /usr/local/lib/libtorrent.so.14(_ZN7torrent7performEv+0x119) [0x7feacea82809]
8 rtorrent() [0x4a69c2]
9 rtorrent() [0x413a2a]
10 /lib/libc.so.6(__libc_start_main+0xfd) [0x7feaccf50c4d]
11 rtorrent() [0x40fe79]
Aborted

Below are some problems that I have had since day 1 but never bothered to actually fix. I have decided to update my rTorrent in hopes that it might resolve my issues but I have found nothing on the matter in the change log so I have liittle hope. I am running rtorrent 0.8.6 and libtorrent 0.12.6. I have been running rutorrent 3.0 but updated it to 3.3 yesterday. It is running on a home-built NAS I have direct access to, running 4GB ECC DDR3, a low power dual core, a very fast array (500+ MB/s) and a 90/80Mbit/s connection.
Here are the issues:

rTorrent chrashes and the output below is displayed when to many torrents are added to the watch directory in to short of a time frame (In my case only about 4 torrents can be added before you have to wait a certain time before adding more).

xxx@xxx:~$ rtorrent
Caught Segmentation fault, dumping stack:
0 rtorrent() [0x43b754]
1 rtorrent() [0x43fb27]
2 /lib/libc.so.6(+0x33af0) [0x7ff6f514faf0]
3 /usr/local/lib/libtorrent.so.11(_ZN7torrent9PollEPoll7performEv+0x91) [0x7ff6f66c7f11]
4 rtorrent() [0x47c11b]
5 rtorrent() [0x43bfaa]
6 /lib/libc.so.6(__libc_start_main+0xfd) [0x7ff6f513ac4d]
7 rtorrent() [0x40ea59]
Aborted

(Second problem was resolved)

A third problem

rTorrent runs out of memory and stops some torrents because of it.
ulimit -u returns unlimited
max_memory_usage is set to 3072M (I have tried without the letter suffix and different ranges without result)
rtorrents still won't use much ram at all and claims to run out. I would gladly let it use more.

Some other issues that may be more related to rutorrent than rtorrent:
-It takes about 10-30sec before torrents added to the watchdirectory can be seen in the web ui. Is it watched with some sort of polling and can the interval be decreased? -resolved, although it still sometimes takes longer that the specified number of seconds
-Web ui is somewhat slow with many torrents
-Partial downloads are marked as downloading when they are in fact finished
-In the category list, 'finished' includes both 'finished and seeding' as well as 'finished and not seeding'. There is no way to check if they are actually seeding without searching through the list and find them and check their status and icon. Why bunch these categories together under the same icon when they have different statuses and icons in the list?

Edit: rtorrent and libtorrent have been updated to 0.8.9 and 0.12.9 respektively and the problems remain, the main one being the first one regarding segmentation fault.

Hello Jari,

as written in my email:

The rutorrent devs would need the real Chunks view transmitted over XMLRPC, i posted my wish here: http://forums.rutorrent.org/index.php?topic=1356.0

For me this is a essential feature when seeding! With this view i can determine superseeding or not and how many bad leechers ive got.

So right now im seeding from a server in the web, and localy "watching" it with Vuze just to have the Chunks View

I hope you can add this wish to your tasklist, im shure there are many people out there wishing this feature!

greetings from Austria,

With the new version i am getting that error. When i try to update tracker it doesn't do anything. Could this be rutorrent bug?

I have seen a definite pattern where all uploads run slowly until a torrent is 100% complete. Before the torrent is complete, the upload speeds are often (slightly) higher than the downloads, but they could clearly be uploading much faster. One of the clearest examples is on the "typical" Chinese HD sites with hundreds of peers and slow-downloading torrents (eg CHD, BHD, HDC): the download obviously can't go any faster but the uploads easily could. Then, as soon as the torrent finishes, I see an instant spike in upload speeds of 5-500%, depending on the peers remaining. The same thing happens even on small, fast-moving torrents from sites where most peers are local (eg BTN, SCC, GFT and many others)

My guess is that the choke manager is limiting upload speeds by giving priority to downloads until the torrent is 100% complete. This is normally a good algorithm but if downloads can't saturate the bandwidth then the uploads still seem to be throttled, wthich is just a waste. Even if this isn't the cause, do you have any theories or even better, a fix?

I'm using svn1272 but AFAIK none of this code has changed since before that.

Hi, sorry for my bad english. I run rtorrent compiled from github (0.9.0/0.13.0) in Ubuntu 11.04 (kernel 2.6.38-13-generic 32 bits). The config of rtorrent is this:

min_peers = 40
max_peers = 100
min_peers_seed = 10
max_peers_seed = 50
max_uploads = 15
download_rate = 96
upload_rate = 96
directory = ~/.rtfiles
session = ~/.rtsession
port_range = 20192-20192
port_random = no
check_hash = yes
use_udp_trackers = yes
encryption=require,require_RC4
dht = on
dht_port = 20192
peer_exchange = yes

I want to encript all traffic, so I add "encryption=require,require_RC4". When I load a normal torrent, this work fine. But when I add a magnet link, rtorrent do not download the metadata file.

I tried to paste only the hash like this "magnet:?xt=urn:btih:8ac3731ad4b039c05393b5404afa6e7397810b41" and the hash and the trackers like this: "magnet:?xt=urn:btih:8ac3731ad4b039c05393b5404afa6e7397810b41&dn=ubuntu-11.10-desktop-i386.iso&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80&tr=udp%3A%2F%2Ftracker.ccc.de%3A80". In the first case, I have added the DHT node to bootstrap (router.utorrent.com, router.bittorrent.com and dht.transmissionbt.com) with de dht_add_node= command.

In both cases, rtorrent detects the size of the metadata but do not download them. The screens of rtorrent in this status are this: {mainwindow} {file list} {peer list} {tracker list}. In the peer list window, the peers appears and disappears constantly. In the main window, the text "Connecting to dht, searching..." appears in the "8AC3..." download sometimes and the number of nodes vary constantly. I waited more than two hours and nothing changes. I have tried with many magnets links, many of them with more than 10000 seeders and leechers.

The workaround which I use is quit rtorrent, deactivate encryption (encryption=none), start rtorrent, wait a few seconds to rtorrent download the metadata and put the download in closed state, quit rtorrent, activate encryption (encryption=require,require_RC4), start rtorrent, and start download (Ctrl+S).

I don't know if this is a bug or is the normal operation. If is the normal operation, is possible to add a new feature to handle this situation?. Something like a new encryption type (encryption=plain_metadata,require_files,require_RC4) to download the metadata unencrypted and the files encrypted.

If you want need more info, debug, capture packets, etc, please let me know. Thanks.