libtorrent crashes (gcc 4.0 issue?)

[anonymous]

When starting a download, rtorrent crashes after a few seconds. This appeared after I switched to gcc 4.0.2 (libtorrent/rtorrent built with gcc 3.4.3 was working fine). The crash happens with both stable and devel branch (tested with 0.7.0-1/0.3.0 and 0.7.5/0.3.5).

Details:

Caught Segmentation fault, dumping stack:  
0 rtorrent [0x8050244]
1 rtorrent [0x805b0cf]
2 [0xffffe420]
3 /usr/lib/libtorrent.so.5(_ZN7torrent11RequestList9has_indexEj+0x21) [0xb7f55e01]
4 /usr/lib/libtorrent.so.5(_ZN7torrent19PeerConnectionLeech22receive_finished_chunkEi+0x56) [0xb7f51196]
5 /usr/lib/libtorrent.so.5(_ZSt8for_eachIN9__gnu_cxx17__normal_iteratorIPPN7torrent18PeerConnectionBaseESt6vectorIS4_SaIS4_EEEESt9binder2ndISt10mem_fun1_tIvS3_iEEET0_T_
SF_SE_+0x6e) [0xb7f3220e]
6 /usr/lib/libtorrent.so.5(_ZN7torrent14ConnectionList19send_finished_chunkEj+0x5a) [0xb7f30d6a]
7 /usr/lib/libtorrent.so.5(_ZN7torrent12DownloadMain17receive_hash_doneENS_11ChunkHandleESs+0x313) [0xb7f3aab3]
8 /usr/lib/libtorrent.so.5(_ZN4sigc8internal10slot_call2INS_18bound_mem_functor2IvN7torrent12DownloadMainENS3_11ChunkHandleESsEEvS5_SsE7call_itEPNS0_8slot_repERKS5_RKSs
+0x9c) [0xb7f42cfc]
9 /usr/lib/libtorrent.so.5(_ZN7torrent9HashQueue5checkEb+0x135) [0xb7f29495]
10 /usr/lib/libtorrent.so.5(_ZN7torrent9HashQueue4workEv+0x42) [0xb7f29642]
11 /usr/lib/libtorrent.so.5(_ZNK4sigc15adaptor_functorINS_18bound_mem_functor0IvN7torrent9HashQueueEEEEclEv+0x3b) [0xb7f2972b]
12 /usr/lib/libtorrent.so.5(_ZN4sigc8internal10slot_call0INS_18bound_mem_functor0IvN7torrent9HashQueueEEEvE7call_itEPNS0_8slot_repE+0x20) [0xb7f29750]
13 /usr/lib/libtorrent.so.5(_ZN7torrent13TaskScheduler7executeENS_5TimerE+0x8a) [0xb7f65faa]
14 /usr/lib/libtorrent.so.5(_ZN7torrent7performEv+0x81) [0xb7f1af61]
15 rtorrent [0x8074372]
16 rtorrent [0x8051f7f]
17 /lib/tls/libc.so.6(__libc_start_main+0xc2) [0xb7b3adf2]
18 rtorrent(__gxx_personality_v0+0x18d) [0x804fce1]
TO AVOID CORRUPT DOWNLOADS, RUN "touch" ON ALL DOWNLOADED FILES OR INITATE HASH RECHECK WITH ^R ON ALL TORRENTS.

[rakshasa]

I've received a similar report from another user. Having looked at the debugging information he provided, it might be a compiler bug. The relevant parts of the code shouldn't cause a problem, unless i'm corrupting some memory in a different part of the code.

[rtorrent@oddsoftware.net]

This is definitely triggered by gcc-4.

Running within valgrind produces some errors, even with gcc-3.4.3, shown here, but runs ok

 ==3170== Syscall param mincore(vec) points to unaddressable byte(s) 
 ==3170==    at 0x1BD56774: mincore (in /lib/libc-2.3.5.so)
 ==3170==    by 0x1B9C94E5: torrent::ChunkPart::incore_length(unsigned) (in /usr/lib/libtorrent.so.5.0.0) 
 ==3170==    by 0x1B9C10EB: torrent::Chunk::incore_length(unsigned) (in /usr/lib/libtorrent.so.5.0.0)
 ==3170==    by 0x1B9CB63F: torrent::HashChunk::perform(unsigned, bool) (in /usr/lib/libtorrent.so.5.0.0)
 ==3170==    by 0x1B9CB9D0: torrent::HashQueue::check(bool) (in /usr/lib/libtorrent.so.5.0.0)
 ==3170==    by 0x1B9CBD40: torrent::HashQueue::work() (in /usr/lib/libtorrent.so.5.0.0)
 ==3170==    by 0x1B9CC9C5: sigc::adaptor_functor<sigc::bound_mem_functor0<void, torrent::HashQueue> >::operator() () const (in /usr/lib/libtorrent.so.5.0.0)
 ==3170==    by 0x1B9CC9EF: sigc::internal::slot_call0<sigc::bound_mem_functor0<void, torrent::HashQueue>, void>::call_it(sigc::internal::slot_rep*) (in /usr/lib/libtorrent.so.5.0.0)
 ==3170==    by 0x1BA0DBF5: torrent::TaskScheduler::execute(torrent::Timer) (in /usr/lib/libtorrent.so.5.0.0)
 ==3170==    by 0x1B9BD498: torrent::perform() (in /usr/lib/libtorrent.so.5.0.0)
 ==3170==    by 0x807ACB1: (within /usr/bin/rtorrent)
 ==3170==    by 0x8054BD6: (within /usr/bin/rtorrent)
 ==3170==  Address 0x52C00000 is not stack'd, malloc'd or (recently) free'd
 ==3170== 

With gcc-4.0.2, from GDB we get:

 #0  0xb7ebda21 in torrent::RequestList::has_index () from /usr/lib/libtorrent.so.5
 #1  0xb7eb69f2 in torrent::PeerConnectionLeech::receive_finished_chunk () from /usr/lib/libtorrent.so.5
 #2  0xb7e88644 in torrent::ConnectionList::send_finished_chunk () from /usr/lib/libtorrent.so.5
 #3  0xb7ea31e9 in torrent::DownloadWrapper::receive_hash_done () from /usr/lib/libtorrent.so.5
 #4  0xb7e7fe8d in torrent::HashQueue::check () from /usr/lib/libtorrent.so.5
 #5  0xb7e80532 in torrent::HashQueue::work () from /usr/lib/libtorrent.so.5
 #6  0xb7e8061b in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, torrent::HashQueue>, void>::call_it ()
   from /usr/lib/libtorrent.so.5
 #7  0xb7ed35be in torrent::TaskScheduler::execute () from /usr/lib/libtorrent.so.5
 #8  0xb7e64a11 in torrent::perform () from /usr/lib/libtorrent.so.5
 #9  0x08090702 in __gnu_cxx::__mt_alloc<std::_List_node<torrent::Peer>,  __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate ()
 #10 0x08055a42 in __gnu_cxx::__common_pool<__gnu_cxx::__pool, true>::_S_get_pool ()
 #11 0xb7a9a3b3 in __libc_start_main () from /lib/libc.so.6
 #12 0x0804ef01 in ?? ()

[rakshasa]

The valgrind error message is propably invalid, as it would be pointing to mmap'ed memory. Are you using an up-to-date version of Valgrind?

The second one is most likely a compiler bug, as the code in question is almost certainly correct. (Atleast considering the way in which the 4.0.2 compiler fails there)

[anonymous]

Compiling libtorrent and rtorrent with CXXFLAGS="-fno-strength-reduce -fno-thread-jumps -fno-inline -fforce-addr" seems to produce stable code (gcc 4.0.2).

[frodoontop]

Gcc-4.1 no longer produces the crash.

[Bary]

For me was this: CXXFLAGS="-fno-strength-reduce -fno-thread-jumps -fno-inline -fforce-addr" the wizard key!!!! And I've got gcc-4.0.3

Thx very much for your posts.