Note: This is relevant to any ARM based device running Linux
I’m trying to use a Raspberry Pi as a torrentbox (an always-on
If I ever finish this project, I’ll defiantly post my build.
Anyway, I had a really annoying problem - every once in a while, the Deluge daemon would crash, printing only this message as a reason:
(Meaning that the program tried to access a part of the memory it’s not allowed to.)
I made sure I’m running the latest version of deluge (as offered by the
rPi debian repository), and attempted to troubleshoot.
I tried running deluge using debug logging, but found no consistent message pattern before the crash, probably meaning that the code causing the fault wasn’t message-worthy or it meant to log its action after the line responsible for the crash.
Since then I’ve been ignoring it and simply restarting the daemon every now and then, but today it wouldn’t stay running for 5 minutes, so I had to do something.
Even though I know very little about Linux troubleshooting, I’ve decided to try and use GDB (GNU Debugger) to try and understand the cause.
I used these commands to recreate the problem in gdb:
$ gdb --args python /usr/bin/deluged -d -L info (gdb) handle SIGILL nostop (gdb) run
deluged (deluge daemon) arguments are used to tell deluged to avoid
“daemonising” (so to stay attached to console) and to log to screen
handle line is because libcrypto is testing the CPU features on
initialization, and creates (and handles) a fake “Illegal Instruction”
run tells deluged to start executing, and then we wait for the
The crash looked something like this:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb5a5e470 (LWP 10169)] RC4 () at /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
So the “guilty” code is libcrypto. Let’s search for its owner:
$ apt-cache search libcrypto libcrypto++-dev - General purpose cryptographic library - C++ development libcrypto++-doc - General purpose cryptographic library - documentation libcrypto++-utils - General purpose cryptographic library - utilities and data files libcrypto++9 - General purpose cryptographic library - shared library libcrypto++9-dbg - General purpose cryptographic library - debug symbols libcryptokit-ocaml - cryptographic algorithm library for OCaml - runtime libcryptokit-ocaml-dev - cryptographic algorithm library for OCaml - development libssl-dev - SSL development libraries, header files and documentation libssl-doc - SSL development documentation documentation libssl1.0.0 - SSL shared libraries libssl1.0.0-dbg - Symbol tables for libssl and libcrypto
As we can see, it’s part of
libssl1.0.0. Since these are also
up-to-date, I don’t want to touch them. After examining the backtrace in
(gdb) thread apply all backtrace ... Thread 3 (Thread 0xb5a5e470 (LWP 10169)): #0 0xb6568c7c in RC4 () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 #1 0xb67acee4 in libtorrent::bt_peer_connection::send_buffer(char const*, int, int) () from /usr/lib/libtorrent-rasterbar.so.6 #2 0xb67ab3ec in libtorrent::bt_peer_connection::append_const_send_buffer(char const*, int) () from /usr/lib/libtorrent-rasterbar.so.6 #3 0xb68b6b30 in ?? () from /usr/lib/libtorrent-rasterbar.so.6 #4 0xb68b6b30 in ?? () from /usr/lib/libtorrent-rasterbar.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) ...
I can see it’s being called by
it’s probably related to peer-to-peer encryption.
Disabling it wasn’t trivial either - since I couldn’t get deluged to run for more than one minute, I had to edit the configuration file manually.
After editing the file
~/.config/deluge/core.conf and changing these
settings (UI equivalent in brackets):
Network > Encryption > Level) from
Network > Encryption > Encrypt entire stream) from
Everything seems to be normal now.
I’m still not fully aware what are
the friendly names of those settings. Thanks Lucas for the setting names!
Of course this is only a workaround, but at least I can use Deluge again.
What an adventure!