Crash in libtorrent::aux::session_impl::on_disk_queue (FreeBSD72)

[GoogleCodeExporter]

I have this crash quite frequently doing add/remove/download torrents <1gb size

(gdb) bt
#0  0x00000000a4ba5e89 in libtorrent::aux::session_impl::on_disk_queue 
(this=Variable "this" is not available.
) at atomic_count_gcc_x86.hpp:67
#1  0x0000000000a4b184 in ?? ()
#2  0x0000000000000000 in ?? ()
#3  0x00000000a50e0dc0 in guard variable for 
boost::system::system_category()::system_category_const () from 
/skynet/python/lib/libboost_system.so.1.46.1
#4  0x00000000a4edbf51 in void 
boost::function0<void>::assign_to<boost::_bi::bind_t<void, 
boost::_mfi::mf0<void, libtorrent::aux::session_impl>, 
boost::_bi::list1<boost::_bi::value<libtorrent::aux::session_impl*> > > 
>(boost::_bi::bind_t<void, boost::_mfi::mf0<void, 
libtorrent::aux::session_impl>, 
boost::_bi::list1<boost::_bi::value<libtorrent::aux::session_impl*> > 
>)::stored_vtable () from /skynet/python/lib/libtorrent-rasterbar.so.6
#5  0x00000000a4ba5e30 in libtorrent::aux::session_impl::~session_impl () at 
stl_tree.h:614
#6  0x0000000000000000 in ?? ()
#7  0x00000000a6292000 in ?? ()
#8  0x00000000a4edbf51 in void 
boost::function0<void>::assign_to<boost::_bi::bind_t<void, 
boost::_mfi::mf0<void, libtorrent::aux::session_impl>, 
boost::_bi::list1<boost::_bi::value<libtorrent::aux::session_impl*> > > 
>(boost::_bi::bind_t<void, boost::_mfi::mf0<void, 
libtorrent::aux::session_impl>, 
boost::_bi::list1<boost::_bi::value<libtorrent::aux::session_impl*> > 
>)::stored_vtable () from /skynet/python/lib/libtorrent-rasterbar.so.6
#9  0x00000000a4ba5e30 in libtorrent::aux::session_impl::~session_impl () at 
stl_tree.h:614
#10 0x0000000000000000 in ?? ()
#11 0x00000000a6292000 in ?? ()
#12 0x00007fffff5fbd20 in ?? ()
#13 0x0000000000000000 in ?? ()
#14 0x0000000000000000 in ?? ()
#15 0x0000000000000000 in ?? ()
#16 0x000000009da7b740 in ?? ()
#17 0x00000000a71bbb01 in ?? ()
#18 0x00007fff00000001 in ?? ()
#19 0x0000000000000000 in ?? ()
#20 0x00000000a4b7d200 in libtorrent::bitfield::resize (this=0x0, 
bits=-1303379840, val=164) at bitfield.hpp:257
#21 0x6800007fffff5fbe in ?? ()
#22 0x000000009da7b668 in ?? ()
#23 0x00000000004cdccf in ?? ()
#24 0x000000009da7b658 in ?? ()
#25 0x000000009da7b67c in ?? ()
#26 0x00007fffff5fbdf0 in ?? ()
#27 0x0000000000000000 in ?? ()
#28 0x0000000000000000 in ?? ()
#29 0x0000000000001010 in ?? ()
#30 0x0000000000000000 in ?? ()
#31 0x000000009da7b630 in ?? ()
#32 0x00007fffff5fbea0 in ?? ()
#33 0x00007fffff5fbe80 in ?? ()
#34 0x0000000000001000 in ?? ()
#35 0x00000000a4233080 in ?? ()
#36 0x00000000a422c000 in ?? ()
#37 0x0000000000000000 in ?? ()
#38 0x000000009d5ae94a in free () from /lib/libc.so.7
#39 0x00000000a50e0dc0 in guard variable for 
boost::system::system_category()::system_category_const () from 
/skynet/python/lib/libboost_system.so.1.46.1
#40 0x000000009da7b658 in ?? ()
#41 0x00000000a421b000 in ?? ()
#42 0x000000009da7b630 in ?? ()
#43 0x0000000000000000 in ?? ()
#44 0x0000000000000000 in ?? ()
#45 0x00000000a6292000 in ?? ()
#46 0x000000009d806578 in ?? ()
#47 0x000000009d8020b0 in ?? ()
#48 0x00007fffff5fbf20 in ?? ()
#49 0x000000009d9f2840 in ?? ()
#50 0x0000000000000000 in ?? ()
#51 0x00000000a4ba91a5 in libtorrent::aux::session_impl::operator() 
(this=0x1000) at io_service.ipp:64
#52 0x0000000000a530ba in ?? ()
#53 0x0000000000000000 in ?? ()
#54 0x0000000000000000 in ?? ()
#55 0x000000009d9f2840 in ?? ()
#56 0x00000000a43e8e40 in ?? ()
#57 0x000000009d9f2840 in ?? ()
#58 0x00000000a43e8e40 in ?? ()
#59 0x0000000000000000 in ?? ()
#60 0x000000009d806570 in ?? ()
#61 0x000000009d806578 in ?? ()
#62 0x000000009d42e4d1 in pthread_getprio () from /lib/libthr.so.3
#63 0x0000000000000000 in ?? ()
Error accessing memory address 0x7fffff5fc000: Bad address.

Original issue reported on code.google.com by mocksoul on 2 May 2011 at 10:33

[GoogleCodeExporter]

Oh yes, I'm using latest RC_15_0 code.

Original comment by mocksoul on 2 May 2011 at 10:34

[GoogleCodeExporter]

That stack looks quite corrupt. Are you sure the symbols matches your binary?

Which thread is it that crashes? What are the other threads doing at the time?

Original comment by arvid.no...@gmail.com on 3 May 2011 at 7:46

[GoogleCodeExporter]

I can reproduce this running under gdb while building with -ggdb, -DDEBUG and 
_without_ --enable-debug in libtorrent. I tried --enable-debug, but too many 
asserts occur. I dont know is that normal or not - we can analyze them as well 
if needed :).

And since I'm still not very strong in C/C++ dev -- you can ask me to do 
everything you need under gdb :).

Original comment by mocksoul on 3 May 2011 at 11:22

[GoogleCodeExporter]

does it happen with optimization turned off as well (i.e. -O0)? It looks like 
the stack is completely corrupt, but there is a chance that it just looks odd 
because it's an optimized build and gdb can't figure it out. Either that or the 
debug symbols don't match the executable.

Original comment by arvid.no...@gmail.com on 23 May 2011 at 9:10