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.

[Carol <caroll@yahoo.com>]

I think that it is necessary to have up-to-date version of Valgrind  writing service.

[anonymous]

What the matter is? Why the problems happen again and again?  http://www.astrabeds.com/latex-mattresses.html

[anonymous]

Definetly does work with the most up to date version of Valgrind, I used this torrent as part of my  groom wedding speech and at the end of it I nearly had to know  how to fight it got that rowdy!

[Paul]

So this was the reason for the crash, now I know. I've been looking at this lately in connection to my  http://www.electronicdrumsetreviews.net/ site that I'm currently working

[james]

Thanks for the script, I've been working on this bug for quite some time now. I have been having this problem to one of my pages -  http://www.chapmanroofing.com/flat-roof-roofing-material/

[Mike]

Hope its really work <a class="ext-link" href=" http://www.vibratorwarehouse.com/butt-plugs/"><span class="icon"> </span>butt plug</a>.

[anonymous]

Hua 110107Going to an amusement classic short uggs park or ball game, watching a movie or television, are fun activities that help us relax, temporarily forget our problems and maybe even laugh. But they do not bring happiness, because their ugg bailey button boots positive effects end when the fun ends.  http://www.fitflopinuk.com/

[ctxgCK]

yUSoxkK