Opened 11 years ago

Closed 8 years ago

#2272 closed bug (Fixed)

deluged segfaults within few minutes after start

Reported by: incanus Owned by:
Priority: major Milestone: not applicable
Component: libtorrent Version: 1.3.6
Keywords: segfault Cc: bart@…, xavier@…

Description

I'm running deluged and deluge-web (installed from wheezy repo) on debian 7.0 server with no X installed. Recently it started segfaulting within 10 minutes after start. I tried to purge it completely (removed .config/deluge too) and reinstalling, but that doesn't help. The log shows:

segfault at 7fb0680bc000 ip 00007fb071200446 sp 00007fb06eb53aa0 error 4 in libcrypto.so.1.0.0

(the adresses changing every time). sometimes this appears in the log also:

general protection ip:4a19bf sp:7fff5de09000 error:0 in python2.7

Tried running from gdb, but shows nothing more than the segfault in libcrypto. strace doesn't seem to show anything userful either:

...
gettimeofday({1360435642, 679110}, NULL) = 0
poll([{fd=8, events=POLLIN}, {fd=25, events=POLLIN}, {fd=5, events=POLLIN}, {fd=41, events=POLLIN}], 4, 49 <unfinished ...>
+++ killed by SIGSEGV +++

libtorrent version - 0.15.10.0

libssl version - 1.0.1c-4 (libcrypto.so.1.0.0 belongs to libssl package)

python version - 2.7.3

Change History (7)

comment:1 Changed 11 years ago by Cas

  • Component changed from core to other
  • Milestone changed from 1.3.x to not applicable

Unfortunately this is not likely to be Deluge/libtorrent related. It has been reported on Debian Bug tracker but after updates was closed.

Did you install libssl1.0.0-dbg when attempting the backtrace?

Are you able to identify any specific torrent causing the issue?

Also have you tried installing libssl0.9.8?

For reference this also affects Ubuntu 12.04:

comment:2 Changed 11 years ago by incanus

Oh, didn't know that the -dbg package is needed, this was my first time using gdb. Ok, after installing libssl1.0.0-dbg, this shows up:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff3659700 (LWP 9889)]
RC4 () at rc4-x86_64.s:128
128     rc4-x86_64.s: No such file or directory.
(gdb) backtrace
#0  RC4 () at rc4-x86_64.s:128
#1  0x0000000000000000 in ?? ()

I've looked up the rc4-x86_64.s no such file error and it really seems there's some problem with the libssl1.0.0 package. I also ran aptitude full-upgrade, but no update for libssl was found. libssl0.9.8 isn't in the testing repo, but if no update appears shortly, I'll add stable repo and try to downgrade and report here.

Just for completeness, the torrent I made the backtrace with was this one: http://thepiratebay.se/torrent/7710871/naruto_shippuden_season_10 but I'm pretty sure this happened earlier too.

Thanks for you help, Cas.

comment:3 Changed 11 years ago by tremby

  • Cc bart@… added

I'm getting the same crash, many times per day.

comment:4 Changed 11 years ago by ozamosi

I had the same problem (I don't mean that in the "it crashes, this bug is about crashes, must be the same!", but as in yes, gdb said the crash was in RC4() - I was preparing these nice, long backtraces with loads of debug symbols, but then my terminal decided to break and throw away my backlog, and meanwhile I appear to have fixed the problem - darn!) - not on debian but on fedora, using the latest deluge and libtorrent 0.15.9. So roughly the same libtorrent version as the original reporter.

It only happened when adding "bad" torrents. Then it crashed somewhere between every hour or two down to more often than every minute. Pausing the "bad" torrents would make the problem go away - though paused torrents don't download no more :( Sometimes disabling encryption - or enforcing it - would also make deluge stop crashing.

Upgrading libtorrent to 0.16.8 made the problem go away. I was still downloading the same files, and deluged would crash about once a minute before the upgrade, while it hasn't crashed in over an hour since.

Looking quickly at the libtorrent changelog, and knowing very little about this stuff at all, a couple of entries look plausibly related - like, say, "resistance towards certain flood attacks" or "made the DHT implementation slightly more robust against routing table poisoning and node ID spoofing".

comment:5 Changed 11 years ago by antoviaque

  • Cc xavier@… added
  • Version changed from 1.3.3 to 1.3.6

I have this issue too on 1.3.6:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff2f3a700 (LWP 3788)]
RC4 () at rc4-x86_64.s:154
154     rc4-x86_64.s: No such file or directory.
(gdb) thread apply all backtrace

Thread 6 (Thread 0x7ffff1106700 (LWP 3791)):
#0  0x00007ffff7bc8d84 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007ffff480e44b in boost::asio::detail::task_io_service::run(boost::system::error_code&) () from /usr/lib/libtorrent-rasterbar.so.6
#2  0x00007ffff480e716 in boost::asio::detail::posix_thread::func<boost::asio::detail::resolver_service_base::work_io_service_runner>::run() () from /usr/lib/libtorrent-rasterbar.so.6
#3  0x00007ffff480a36e in boost_asio_detail_posix_thread_function () from /usr/lib/libtorrent-rasterbar.so.6
#4  0x00007ffff7bc4e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#5  0x00007ffff699eccd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 4 (Thread 0x7ffff2739700 (LWP 3789)):
#0  0x00007ffff7bc8d84 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007ffff480e44b in boost::asio::detail::task_io_service::run(boost::system::error_code&) () from /usr/lib/libtorrent-rasterbar.so.6
#2  0x00007ffff480e716 in boost::asio::detail::posix_thread::func<boost::asio::detail::resolver_service_base::work_io_service_runner>::run() () from /usr/lib/libtorrent-rasterbar.so.6
#3  0x00007ffff480a36e in boost_asio_detail_posix_thread_function () from /usr/lib/libtorrent-rasterbar.so.6
#4  0x00007ffff7bc4e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#5  0x00007ffff699eccd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 3 (Thread 0x7ffff2f3a700 (LWP 3788)):
#0  RC4 () at rc4-x86_64.s:154
#1  0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7ffff373b700 (LWP 3787)):
#0  0x00007ffff7bc8d84 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007ffff47f3db2 in libtorrent::disk_io_thread::operator()() () from /usr/lib/libtorrent-rasterbar.so.6
#2  0x00007ffff3b85ce9 in thread_proxy () from /usr/lib/libboost_thread.so.1.46.1
#3  0x00007ffff7bc4e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#4  0x00007ffff699eccd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#5  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7ffff7fe7700 (LWP 3782)):
#0  0x00007ffff6993313 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00000000004aea55 in ?? ()
#2  0x0000000000466254 in PyEval_EvalFrameEx ()
#3  0x0000000000466a42 in PyEval_EvalFrameEx ()
#4  0x0000000000466a42 in PyEval_EvalFrameEx ()
#5  0x000000000057bd02 in PyEval_EvalCodeEx ()
#6  0x00000000004667f8 in PyEval_EvalFrameEx ()
#7  0x000000000057bd02 in PyEval_EvalCodeEx ()
#8  0x000000000057dcd0 in ?? ()
#9  0x00000000004bf2a6 in PyObject_Call ()
#10 0x00000000004a4b8a in ?? ()
#11 0x00000000004bf2a6 in PyObject_Call ()
#12 0x00000000004a393e in ?? ()
#13 0x00000000004f8cf6 in ?? ()
#14 0x00000000004bf2a6 in PyObject_Call ()
---Type <return> to continue, or q <return> to quit---
#15 0x00000000004668da in PyEval_EvalFrameEx ()
#16 0x000000000057bd02 in PyEval_EvalCodeEx ()
#17 0x00000000004667f8 in PyEval_EvalFrameEx ()
#18 0x000000000057bd02 in PyEval_EvalCodeEx ()
#19 0x000000000057c77d in PyRun_FileExFlags ()
#20 0x000000000057e4a1 in PyRun_SimpleFileExFlags ()
#21 0x0000000000512cfd in Py_Main ()
#22 0x00007ffff68cc76d in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
#23 0x000000000041ba51 in _start ()

It seem similar to an issue also affecting qBittorrent: https://github.com/qbittorrent/qBittorrent/issues/750

comment:6 Changed 10 years ago by aussie5

I had this same problem on Ubuntu 12.04.4 that only occurred when I tried downloading a particular torrent:

Jan 28 11:52:03 localhost kernel: [49243.969951] deluge[725]: segfault at 4d853f0 ip 0
0007fb8da32579e sp 00007fb897ffe150 error 4 in libcrypto.so.1.0.0[7fb8da29c000+1b1
000]

The package versions:

libtorrent-rasterbar6 0.15.10-1
python-libtorrent 0.15.10-1
deluge 1.3.6-0~precise~ppa1
deluge-common 1.3.6-0~precise~ppa1
deluge-gtk 1.3.6-0~precise~ppa1

I found the discussion on this issue at http://forum.deluge-torrent.org/viewtopic.php?f=7&t=41843 where it was suggested the libtorrent version (0.15.10) was the problem. I tried the same problem torrent in an Ubuntu 13.10 VM (libtorrent 0.16.11) and it's downloaded fine with no deluge crashes.

Maybe look at making libtorrent >= 0.16 a dependency for future versions?

comment:7 Changed 8 years ago by Cas

  • Component changed from other/unknown to libtorrent
  • Resolution set to Fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.