Custom Query (2449 matches)

I am using btguard as a proxy service. Deluge always crashes when i apply the btguard settings. I can restart deluge, but it crashes after a few seconds or minutes. The error is always "terminate called after throwing an instance of 'boost::lock_error'"

Can anyone please help.

I posted it here ​http://code.google.com/p/libtorrent/issues/detail?id=161 but here I go again...

Reported by ​monster....@gmail.com, Feb 06 (46 hours ago)

1. Generally downloading torrents to a disk that is full

Expected output is not to crash but to either pause the torrent and inform the user there is no space left, or still inform the user and switch to seed only mode. What I see is a back trace of crashed deluge.

deluge 1.3.1, libtorrent-rasterbar 0.15.5, Linux

Using gdb, I have found this:

assertion failed. Please file a bugreport at ​http://code.rasterbar.com/libtorrent/newticket Please include the following information:

version: 0.15.5.0 $Rev: 5141 $ file: 'storage.cpp' line: 1930 function: int libtorrent::piece_manager::write_impl(libtorrent::file::iovec_t*, int, int, int) expression: offset >= hash_offset stack: 1: assert_fail(char const*, int, char const*, char const*) 2: libtorrent::piece_manager::write_impl(iovec*, int, int, int) 3: libtorrent::disk_io_thread::flush_range(std::_List_iterator<libtorrent::disk_io_thread::cached_piece_entry>, int, int, boost::unique_lock<boost::recursive_mutex>&) 4: libtorrent::disk_io_thread::flush_and_remove(std::_List_iterator<libtorrent::disk_io_thread::cached_piece_entry>, boost::unique_lock<boost::recursive_mutex>&) 5: libtorrent::disk_io_thread::flush_expired_pieces() 6: libtorrent::disk_io_thread::operator()() 7: 8: thread_proxy 9: 10: clone

Program received signal SIGINT, Interrupt. [Switching to Thread 0xb4f67b70 (LWP 17557)] 0xb7fe1424 in kernel_vsyscall () (gdb) bt #0 0xb7fe1424 in kernel_vsyscall () #1 0xb7e410d6 in raise () from /lib/libpthread.so.0 #2 0xb51e448d in assert_fail (expr=0xb543b18a "offset >= hash_offset",

line=1930, file=0xb53e3e1d "storage.cpp", function=0xb543c7a0 "int libtorrent::piece_manager::write_impl(libtorrent::file::iovec_t*, int, int, int)") at assert.cpp:136

#3 0xb5319af2 in libtorrent::piece_manager::write_impl (this=0x8984f40,

bufs=0xb4f66530, piece_index=3118, offset=147456, num_bufs=1) at storage.cpp:1930

#4 0xb521139e in libtorrent::disk_io_thread::flush_range (this=0x8642d14,

e=..., start=0, end=256, l=...) at disk_io_thread.cpp:704

#5 0xb5211c9d in libtorrent::disk_io_thread::flush_and_remove (

this=0x8642d14, e=..., l=...) at disk_io_thread.cpp:662

#6 0xb5211da2 in libtorrent::disk_io_thread::flush_expired_pieces (

this=0x8642d14) at disk_io_thread.cpp:461

#7 0xb5214b31 in libtorrent::disk_io_thread::operator() (this=0x8642d14)

at disk_io_thread.cpp:1561

#8 0xb521f5a1 in boost::detail::thread_data<boost::reference_wrapper<libtorrent::disk_io_thread> >::run() () from /usr/lib/libtorrent-rasterbar.so.6 #9 0xb512cacc in thread_proxy () from /usr/lib/libboost_thread-mt.so.1.45.0 #10 0xb7e38a55 in start_thread () from /lib/libpthread.so.0 #11 0xb7d8573e in clone () from /lib/libc.so.6 (gdb)

Additionally bug report URL needs to be updated.

The GTK UI is showing local file browsers for my connection to a remote deluged instance.

I didn't think the deluge team would be silly enough to do this, and I was right of course, but after diving into the source it seems to me that the client is switching which chooser to display depending on whether the server address is localhost or not. Herein lies the problem: I am connected to a remote deluged instance through an SSH tunnel with my endpoint bound to localhost. That is, yes: the UI is connected to localhost, but no: the deluged instance is not running locally.

Specifically:

• deluged is running on 'remotesvr' on the usual port.
• I open the tunnel like so: "ssh -N -L 58847:localhost:58846 thomas@remotesvr".
• I connect to the remote deluged through the tunnel by pointing my client at localhost:58847.