rtorrent crashes while checking hashes on large files

[cxd@maximilianeum.ch]

rtorrent crashes when checking the hashes on large torrents with the following error:

[ :0] Hashing: Checking hash [30%]                                                                                                                                                  
Caught Bus error, dumping stack:0/  0.0 KB] [Port: 9082]                                                                             [U 0/6] [D 0/0] [H 0/32] [S 0/3/768] [F 22/128]
Stack dump not enabled.                                                                                                                                                             
A bus error probably means you ran out of diskspace.                                                                                                                                
Aborted

However the disks still have plenty of space left (~15GB on the disk rtorrent is running on). The only way to fix this problem is by deleting the torrent, which is really bad.

[josef]

Apparently your system's freeaddrinfo implementation doesn't accept NULL arguments. However since that isn't standards-compliant usage anyway, it should be considered a bug in rtorrent.

Try this patch, it should fix it:  http://ovh.ttdpatch.net/~jdrexler/rt/fix_scgi_crash.diff

[josef]

Crap, replied to the wrong ticket. Disregard the above.

[josef]

What rtorrent/libtorrent version? What machine? What OS? What compiler was used to compile rtorrent/libtorrent? How big is the torrent?

While it's hashing, observe the memory usage in the download info. Is it stable or does it keep rising? If it's stable, check again with `top'.

[anonymous]

I seem to have run into the same problem. I am running rtorrent/libtorrent from svn (build 1087) compiled with
gcc (g++) (Ubuntu 4.3.2-1ubuntu12) 4.3.2 on Ubuntu 8.10, kernel 2.6.27-7.16.

After a start of a single torrent of size 4378.6MB rtorrent aborted with the following
message:

[ :0] Hashing: Checking hash [ 8%]

Caught Bus error, dumping stack:0/  0.0 KB] [Port: 6890]

Stack dump not enabled.

A bus error probably means you ran out of diskspace.

Aborted

On a second attempt rtorrent crashed again with a slightly more verbose output:

[ :0] Hashing: Checking hash [ 9%]

Caught Bus error, dumping stack:1/  0.1 KB] [Port: 6890]

0 /usr/local/bin/rtorrent [0x807dc81]

1 /usr/local/bin/rtorrent [0x8082380]

2 [0xb8089400]

3 /usr/lib/i686/cmov/libcrypto.so.0.9.8(sha1_block_asm_data_order+0x25) [0xb7c87e25]

A bus error probably means you ran out of diskspace.

Aborted

Here is (a part of) what the info page showed at the time of crash:

File stats:         single 1 files

Chunks:             0/1095*4194304

Priority:           2

Peer exchange:      enabled active (0/8)

State changed:      0:05:01

Memory usage:       120.0MB

Max memory usage:   819.2MB

Free diskspace:   55517.9MB

Safe diskspace:     632.0MB

Note the value of "Memory usage". Normally, with min/max = 5/30 I would not get more than 10.0-12.0 MB here. And obviously, there is plenty of free diskspace available (an HFS file system on an external usb hard drive).

Is this something to do with the values of "hash_read_ahead", "hash_interval", "hash_max_tries", parameters? What are their default values or how are they being computed? (The values of these were NOT set in my .rtorrent.rc.) I am relatively new to rtorrent and I have not have time to look at the code closely.

[anonymous]

HFS or HFS+? Because HFS only supports files up to 2GB in size.

And memory usage increases with chunk size (the 4MB chunks here are on the large side), so it's possible that you're running out of memory, or perhaps hitting a ulimit.

[anonymous]

My apology. It is HFS+, non-journaled. The memory hypothesis will need more investigation.

[rakshasa]

Probably hitting one of the bugs in openssl.

[anonymous]

I had this same problem. I found out that it was bad blocks on my USB external drive. Try running fsck -c /dev/[your torrent partition].