wiki:LibTorrentKnownIssues

Known Issues

  1. Compiler bugs
    1. Blacklist
    2. Bad code produced with -fomit-frame-pointer
    3. return-statement with a value, in function returning 'void'
    4. MacOSX 10.5 leopard
    5. Incomplete alignment test
    6. NSLU2 routers and xscale based devices
    7. OpenWRT builds using -fnortti
  2. Disk
    1. Failed chunks with kernel 2.6.19
    2. ReiserFS and 4GB files
    3. Adding torrents on vfat may block
    4. Slow hash checking on *BSD
    5. Madvise call fails on MacOSX 10.3
    6. Lost data when writing to NFS on Linux <2.6.13
    7. Lack of diskspace is not reported properly
  3. Network
    1. Inability to connect to trackers or announces time out
  4. Upgrade Incompatibilities
    1. 0.8.0 Session Files Changed

Compiler bugs

See also CompilationHelp.

Blacklist

  • gcc-4.2.0: Must compile with -fno-strict-aliasing, see #926.
  • gcc-4.1.1: -O2: Causes memory leak, compile with -Os or -O3. (Fixed in libTorrent 0.11.0.)
  • gcc-4.0.2: See #77. (Check the note about certain CXXFLAGS though.)
  • gcc-4.0.0 apple: See #96.

Bad code produced with -fomit-frame-pointer

Several Gentoo users have had problems when using gcc's -fomit-frame-pointer optimization. Gcc seems to produce bad code for C++ exception catching when this flag is used on x86 architecture (probably due to the limited number of registers and the debug information crippled by the flag).

Using libtorrent-0.6.7-r1 and rtorrent-0.2.7-r1 (and further) from Gentoo's Portage avoid this issue (filtering -fomit-frame-pointer flag for x86 systems).

return-statement with a value, in function returning 'void'

The rak/functional.h code contains code that returns the result of void functions, which is legal but fails to compile on certain compiler builds. Apple's gcc-4.0.0 build is amongst those. See #96 for a patch to rak/functional.h.

MacOSX 10.5 leopard

See #1117 for information.

Incomplete alignment test

The alignment test used in libtorrent's configure script does not automatically detect the requirement on all platforms. Use --enable-aligned to manually enable it.

NSLU2 routers and xscale based devices

Due to what appears to be a compiler bug, before configuring set CXXFLAGS="-O2 -mcpu=xscale -mtune=xscale".

OpenWRT builds using -fnortti

Some versions of OpenWRT build system use -fnortti as a compile option, which doesn't work when a program needs dynamic_cast.


Disk

Failed chunks with kernel 2.6.19

Linux version 2.6.19 appears to have a bug in the synching of mmapped files, leading to large numbers of failed chunks when downloading a torrent. Using rTorrent with kernel 2.6.19 is not recommended, but if an earlier kernel version is not an option, make sure to enable the "check_hash" option and manually restart torrents until all chunks pass the hash check. Kernel 2.6.20-rc3 has fixed this problem, so this version and later ones should be safe.

ReiserFS and 4GB files

Downloading files larger than 4GB on ReiserFS (v3) may cause data beyond offset 232 bytes to be written to the start of the file. This will cause the client to enter a cycle of downloading the remaining data then checking the hash.

Adding torrents on vfat may block

When the ftruncate call fails to resize the files on f.ex vfat, then it will create the files by writing a byte to extend the file size. This may block for a while.

Slow hash checking on *BSD

See ticket:14, possibly you might need to adjust "hash_read_ahead" as too high a value might make the kernel give up the read-ahead or something.

Madvise call fails on MacOSX 10.3

See #70 for a patch, remember to set "hash_max_tries = 1" to get decent hashing performance.

Lost data when writing to NFS on Linux <2.6.13

Apparently due to a bug in the NFS client and/or kernel itself for 2.6 kernels before 2.6.13, data is lost when writing to an NFS share using mmap() and msync() with MS_ASYNC. While rtorrent will think the data has been written correctly, the data is never written to the NFS server due to this kernel bug, and hash checks will fail and rtorrent will upload bad data as soon as it disappears from the file cache.

Lack of diskspace is not reported properly

FIXED: Since libTorrent only calls truncate on the files and does not touch the file pages, the kernel does not raise SIGBUS until we call msync when closing the torrents. This results in the kernel throwing away unwritten pages after rtorrent has saved the session torrents. Thus the session torrents have invalid fast-resume data.


Network

Inability to connect to trackers or announces time out

Usually due to a buggy libcurl version. Since version 0.8.2, rtorrent uses more advanced features of libcurl. While these work for many users, in unknown circumstances (depending on system setup? trackers?) it may cause announces to fail consistently. In that case please update libcurl to version 7.19.2 or higher.


Upgrade Incompatibilities

0.8.0 Session Files Changed

Due to a change in the interpretation of session files, multi-file torrents' session files will be incompatible in the transition from pre-0.8.0 to 0.8.0 and beyond, resulting in errors like #1204 and #1232. Running  fixSession080.py on your session directory AFTER you have shutdown rtorrent should resolve the issue. Contact lostnihilist with problems with the script.