Bug#365834: rtorrent: fails to connect to tracker on a multihomed system

2006-05-05 Thread Jari Petter Sundell

On Thu, 4 May 2006, Qingning Huo wrote:


On Thu, May 04, 2006 at 12:29:17PM +0200, Kiko Piris wrote:

On 03/05/2006 at 11:16 +0200, Kiko Piris wrote:


I have a system with 3 ip addresses. I use it to launch 2 instances of
rtorrent binding with -b to each one of the secondary addresses
(eth0:1 and eth0:2).

Version 0.5.0-1 isn't able to connect to the tracker at all.


Specifying the ip address to bind in ~/.rtorrent.rc does work
correctly.



It has previously been reported and fixed:

http://libtorrent.rakshasa.no/ticket/206
http://libtorrent.rakshasa.no/attachment/ticket/206/mislocated_bind.diff

Rakshasa

Wheat on black, lightly sprinkled with subdued colors; the color of code.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#362096: rtorrent: doesn't properly check for write errors

2006-05-01 Thread Jari Petter Sundell

On Tue, 25 Apr 2006, Qingning Huo wrote:


On Wed, Apr 12, 2006 at 10:07:45AM +0200, Yann Vernier wrote:

Package: rtorrent
Version: 0.4.5-1
Severity: normal

While downloading to a nearly full disc, rtorrent will assume writes
succeed and download much more than it could store. I don't know if this
also makes it send incorrect data.


Hi Yann,

Thanks for your bug report.  I am CC'ing the upstream author of rtorrent
because this seems to be a upstream problem.

Jari, what is your thinking of the bug report?


Sorry for the late reply, got distracted by other things.

Linux 2.4 used to send a SIGBUS when the client tried to write to a full 
disk. According to my cursory tests, on 2.6 it silently drops the pages 
when the disk is full and it is forced to page out the data.


This would be detectable if I was using blocking msync as it would return 
an error on full disk, non-blocking msync does not give any such error. To 
fix this a separate thread could run msync (and hashing) in a blocking 
manner.


Due to time constraints I haven't had time to fix this.

Rakshasa

Wheat on black, lightly sprinkled with subdued colors; the color of code.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#347429: rtorrent: Change in priority for a file results in crash

2006-01-10 Thread Jari Petter Sundell

On Tue, 10 Jan 2006, Qingning Huo wrote:


[Add Jaris (the upstream author) to CC]

On Tue, Jan 10, 2006 at 05:40:02PM +0100, Per Andersson wrote:

Package: rtorrent
Version: 0.4.1-1
Severity: normal

Trying to change the priority on a single file
for a torrent results in rtorrent crashing and
giving this error message:

Caught exception from libtorrent:
ChunkSelector::find_range(...) received an
invalid range.

This did not happen in the previous version
(0.3.4-1?) of rtorrent.


Per Andersson



Hi,

Thanks for the bug report.

I have tried what you described, but failed to crash rtorrent (0.4.1-1).
Would you be able to get a core dump file and maybe a gdb backtrace?
That would help the developers to find the problem.

Jaris, how do you think this problem?

Regards,
Qingning


I belive this bug was fixed right after the 0.4.1 release by the patch 
below. It would crash when changing priorities on a torrent that was 
closed (never started).


http://rakshasa.no/downloads/chunk_selector_empty.diff

Rakshasa

Wheat on black, lightly sprinkled with subdued colors; the color of code.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]