26.06.2012 в 17:51:02 +0200 Benoît Knecht напиÑал: > Stepan Golosunov wrote: > > rtorrent 0.9.2-1 crashed upon start several times when I tried it > > couple of weeks ago. (Today it did not crash yet, but this seems to be > > the usual behavior when I am trying to reproduce crash for the bug > > report.)
Upon returning home I found rtorrent crashed. And upon restart it did crashed again immediately with Caught Segmentation fault, dumping stack: Stack dump not enabled. in the screen, but the process did not exit. gdb shown the following: 0xf77a2425 in __kernel_vsyscall () (gdb) bt #0 0xf77a2425 in __kernel_vsyscall () #1 0xf739a6c1 in __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:95 #2 0xf73314d7 in _L_lock_9662 () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #3 0xf732fd06 in *__GI___libc_free (mem=0x9094098) at malloc.c:3736 #4 0xf74c426f in operator delete(void*) () from /usr/lib/i386-linux-gnu/libstdc++.so.6 #5 0xf7611ea9 in std::tr1::_Function_base::_Base_manager<std::tr1::_Bind<std::tr1::_Mem_fn<void (torrent::log_buffer::*)(char const*, unsigned int, int)> (torrent::log_buffer*, std::tr1::_Placeholder<1>, std::tr1::_Placeholder<2>, std::tr1::_Placeholder<3>)> >::_M_manager(std::tr1::_Any_data&, std::tr1::_Any_data const&, std::tr1::_Manager_operation) () from /usr/lib/i386-linux-gnu/libtorrent.so.14 #6 0xf760e228 in torrent::log_cleanup() () from /usr/lib/i386-linux-gnu/libtorrent.so.14 #7 0x0805aade in ?? () #8 0x0809901d in ?? () #9 <signal handler called> #10 0xf732b73a in malloc_consolidate (av=<optimized out>) at malloc.c:5161 #11 0xf732cbd5 in _int_free (av=<optimized out>, p=0x98c3d58) at malloc.c:5034 #12 0xf732fd0d in *__GI___libc_free (mem=0x98c3d60) at malloc.c:3738 #13 0xf74c426f in operator delete(void*) () from /usr/lib/i386-linux-gnu/libstdc++.so.6 #14 0xf74c42bb in operator delete[](void*) () from /usr/lib/i386-linux-gnu/libstdc++.so.6 #15 0xf763ebd1 in ?? () from /usr/lib/i386-linux-gnu/libtorrent.so.14 #16 0xf763eeff in ?? () from /usr/lib/i386-linux-gnu/libtorrent.so.14 #17 0xf75e6b4e in torrent::PollEPoll::perform() () from /usr/lib/i386-linux-gnu/libtorrent.so.14 #18 0xf75e6beb in torrent::PollEPoll::do_poll(long long, int) () from /usr/lib/i386-linux-gnu/libtorrent.so.14 #19 0xf762293c in torrent::thread_base::event_loop(torrent::thread_base*) () from /usr/lib/i386-linux-gnu/libtorrent.so.14 #20 0x08059f24 in ?? () #21 0xf72d3e46 in __libc_start_main (main=0x8056830, argc=1, ubp_av=0xff936fb4, init=0x8155c20, fini=0x8155c10, rtld_fini=0xf77b1590, stack_end=0xff936fac) at libc-start.c:228 #22 0x0805a529 in ?? () I had to use kill -9 afterwards. > > There are usually several dozens of torrents from jamendo in the session > > directory. > > Thanks for the additional information. I'll try to reproduce this bug, > but I'll have to get DHT working first. > > One more thing: Have you seen this bug happening if you only have a few > active torrents? How many are "several dozens"? Are they all active? About 80, all active. I did not really try to run rtorrent with few torrents recently, but I think I was unable to reproduce it with 0.8.9-2 with only one torrent. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
