| 1 | [[libtorrentMirror]] |
| 2 | |
| 3 | = Known Issues = |
| 4 | |
| 5 | [[PageOutline(2-3,,inline)]] |
| 6 | |
| 7 | == Compiler bugs == |
| 8 | |
| 9 | See also CompilationHelp. |
| 10 | |
| 11 | === Blacklist === |
| 12 | |
| 13 | * gcc-4.2.0: Must compile with -fno-strict-aliasing, see #926. |
| 14 | * gcc-4.1.1: -O2: Causes memory leak, compile with -Os or -O3. (Fixed in libTorrent 0.11.0.) |
| 15 | * gcc-4.0.2: See #77. (Check the note about certain CXXFLAGS though.) |
| 16 | * gcc-4.0.0 apple: See #96. |
| 17 | |
| 18 | |
| 19 | === Bad code produced with ''-fomit-frame-pointer'' === |
| 20 | |
| 21 | 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). |
| 22 | |
| 23 | 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). |
| 24 | |
| 25 | |
| 26 | === return-statement with a value, in function returning 'void' === |
| 27 | |
| 28 | 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''. |
| 29 | |
| 30 | |
| 31 | === MacOSX 10.5 leopard === |
| 32 | |
| 33 | See #1117 for information. |
| 34 | |
| 35 | === Incomplete alignment test === |
| 36 | |
| 37 | 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. |
| 38 | |
| 39 | === NSLU2 routers and xscale based devices === |
| 40 | |
| 41 | Due to what appears to be a compiler bug, before configuring set CXXFLAGS="-O2 -mcpu=xscale -mtune=xscale". |
| 42 | |
| 43 | === OpenWRT builds using -fnortti === |
| 44 | |
| 45 | Some versions of OpenWRT build system use -fnortti as a compile option, which doesn't work when a program needs dynamic_cast. |
| 46 | |
| 47 | ---- |
| 48 | |
| 49 | == Disk == |
| 50 | |
| 51 | === Failed chunks with kernel 2.6.19 === |
| 52 | |
| 53 | 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. |
| 54 | |
| 55 | === ReiserFS and 4GB files === |
| 56 | |
| 57 | Downloading files larger than 4GB on ReiserFS (v3) may cause data beyond offset 2^32^ 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. |
| 58 | |
| 59 | |
| 60 | === Adding torrents on vfat may block === |
| 61 | |
| 62 | 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. |
| 63 | |
| 64 | |
| 65 | === Slow hash checking on *BSD === |
| 66 | |
| 67 | 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. |
| 68 | |
| 69 | |
| 70 | === Madvise call fails on MacOSX 10.3 === |
| 71 | |
| 72 | See #70 for a patch, remember to set "hash_max_tries = 1" to get decent hashing performance. |
| 73 | |
| 74 | === Lost data when writing to NFS on Linux <2.6.13 === |
| 75 | |
| 76 | 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. |
| 77 | |
| 78 | === Lack of diskspace is not reported properly === |
| 79 | |
| 80 | 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. |
| 81 | |
| 82 | ---- |
| 83 | |
| 84 | == Network == |
| 85 | |
| 86 | === Inability to connect to trackers or announces time out === |
| 87 | |
| 88 | 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. |
| 89 | |
| 90 | ---- |
| 91 | |
| 92 | == Upgrade Incompatibilities == |
| 93 | |
| 94 | === 0.8.0 Session Files Changed === #session80 |
| 95 | |
| 96 | 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 [http://code.google.com/p/rssdler/downloads/list fixSession080.py] on your session directory AFTER you have shutdown rtorrent should resolve the issue. Contact lostnihilist with problems with the script. |