libtorrent segmentation fault on torrent removal

[jetsaredim]

Running 1.3.5 on Ubuntu 12.10.

Consistentky getting a seg fault when trying to remove torrent files from the gtk interface (don't know how to invoke the console/daemon). Doesn't matter what state the torrent is in at the time of attempted removal, deluge will crash. When re-started the torrents have not been removed. Also, I tried turning up the logging by using the -L and -l options, but I don't seem to be getting any output to whatever log files I've specified.

Linked Bugs: ​https://bugs.launchpad.net/ubuntu/+source/deluge/+bug/1049332 ​https://code.google.com/p/libtorrent/issues/detail?id=369

[Cas]

What version of libtorrent?

A segfault can only be diagnosed with a backtrace in gdb.

​http://dev.deluge-torrent.org/wiki/Contributing/BugReporting

[jetsaredim]

libtorrent-rasterbar6-0.16.2-0ubuntu1

Here's the backtrace...

(gdb) backtrace
#0  0x000000000048aaf8 in ?? ()
#1  0x00007fffd540a5c9 in boost::python::converter::shared_ptr_deleter::operator()(void const*) ()
   from /usr/lib/libboost_python-py27.so.1.49.0
#2  0x00007fffd5a5caf3 in std::_List_base<boost::shared_ptr<libtorrent::torrent_plugin>, std::allocator<boost::shared_ptr<libtorrent::torrent_plugin> > >::_M_clear() () from /usr/lib/libtorrent-rasterbar.so.6
#3  0x00007fffd5a452fe in libtorrent::torrent::~torrent() () from /usr/lib/libtorrent-rasterbar.so.6
#4  0x00007fffd5a45749 in libtorrent::torrent::~torrent() () from /usr/lib/libtorrent-rasterbar.so.6
#5  0x00007fffd5a2de3a in libtorrent::piece_manager::~piece_manager() () from /usr/lib/libtorrent-rasterbar.so.6
#6  0x00007fffd592651e in ?? () from /usr/lib/libtorrent-rasterbar.so.6
#7  0x00007fffd5926beb in std::_List_base<std::pair<libtorrent::disk_io_job, int>, std::allocator<std::pair<libtorrent::disk_io_job, int> > >::_M_clear() () from /usr/lib/libtorrent-rasterbar.so.6
#8  0x00007fffd5926c92 in ?? () from /usr/lib/libtorrent-rasterbar.so.6
#9  0x00007fffd590ff5e in ?? () from /usr/lib/libtorrent-rasterbar.so.6
#10 0x00007fffd591d025 in libtorrent::completion_queue_handler(std::list<std::pair<libtorrent::disk_io_job, int>, std::allocator<std::pair<libtorrent::disk_io_job, int> > >*) () from /usr/lib/libtorrent-rasterbar.so.6
#11 0x00007fffd592854e in ?? () from /usr/lib/libtorrent-rasterbar.so.6
#12 0x00007fffd58fc6e6 in boost::asio::detail::task_io_service::do_run_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service::thread_info&, boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation>&, boost::system::error_code const&) () from /usr/lib/libtorrent-rasterbar.so.6
#13 0x00007fffd58ff2de in boost::asio::detail::task_io_service::run(boost::system::error_code&) ()
   from /usr/lib/libtorrent-rasterbar.so.6
#14 0x00007fffd5a00644 in libtorrent::aux::session_impl::main_thread() () from /usr/lib/libtorrent-rasterbar.so.6
#15 0x00007fffd58f2dd7 in boost_asio_detail_posix_thread_function () from /usr/lib/libtorrent-rasterbar.so.6
#16 0x00007ffff7bc4e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#17 0x00007ffff6fd839d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#18 0x0000000000000000 in ?? ()

[Cas]

This should be reported upstream to libtorrent bug tracker.

The solution for now is to use libtorrent 0.15.

[andrewsomething]

This has been reported upstream to libtorrent at:

​https://code.google.com/p/libtorrent/issues/detail?id=369

[Cas]

This has been fixed upstream in libtorrent svn so will be in next 0.16 release.

[Cas]

Patch to disable add_extenstion and use session flags instead for libtorrent extensions

[Cas]

I have added a patch that will fix the issue in the same manor as the libtorrent fix so that Deluge will work with all previous versions of libtorrent.

One thing to note is that the ut_pex extension a.k.a. Peer Exchange will always be enabled regardless of Preferences settings. I will need to deal with greying out/disabling this option in the UIs.

[andrewsomething]

Working great for me here. Thanks for all your work tracking this down Cas!

[Cas]

The removal of ut_pex option for 1.3 would be too messy due to core-client changes and backward compatibility so leaving as-is.

Created another ticket to deal with 1.4 and the extensions: #2218