rtorrent
rtorrent copied to clipboard
rakshasa
rtorrent keeps crashing
Hello,
rtorrent keeps crashing regularly, I've not been able to find why.
OS: Debian 10.2 rtorrent version: 0.9.8 libtorrent: 0.13.8
1576725433 C Caught signal: 'Segmentation fault.
---DUMP---
Caught Segmentation fault, dumping stack:
/usr/local/bin/rtorrent(+0x3a896) [0x55a16c33c896]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730) [0x7f84afef6730]
/lib/x86_64-linux-gnu/libcurl.so.4(+0x38d1d) [0x7f84b00e1d1d]
/lib/x86_64-linux-gnu/libcurl.so.4(curl_multi_socket_action+0x25) [0x7f84b00e1ff5]
/usr/local/bin/rtorrent(+0x138849) [0x55a16c43a849]
/usr/local/lib/libtorrent.so.21(_ZN7torrent9PollEPoll7performEv+0xca) [0x7f84affc91ea]
/usr/local/lib/libtorrent.so.21(_ZN7torrent9PollEPoll7do_pollEli+0x70) [0x7f84affc9420]
/usr/local/lib/libtorrent.so.21(_ZN7torrent11thread_base10event_loopEPS0_+0x110) [0x7f84b00023d0]
/usr/local/bin/rtorrent(+0x39925) [0x55a16c33b925]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f84afa2409b]
/usr/local/bin/rtorrent(+0x3a1ba) [0x55a16c33c1ba]
Anyone here ever faced this issue ?
Hello,
I can the same but sometimes with :
Caught internal_error: Error calling curl_multi_socket_action.
/usr/local/lib/libtorrent.so.21(_ZN7torrent14internal_error10initializeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x20b) [0x7ff47792936b]
rtorrent(+0x138a63) [0x55ac610c4a63]
rtorrent(+0x138ae2) [0x55ac610c4ae2]
rtorrent(+0x3b7ad) [0x55ac60fc77ad]
/usr/local/lib/libtorrent.so.21(_ZN7torrent11thread_base10event_loopEPS0_+0x153) [0x7ff477978413]
rtorrent(+0x39925) [0x55ac60fc5925]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7ff4769b409b]
rtorrent(+0x3a1ba) [0x55ac60fc61ba]
I got the same previous error with libcurl4 7.64.0-4 I tried to install the version from Debian testing and still crash Tried with rtorrent/libtorrent from Debian repo (0.3.7/0.13.7)
Hello,
rtorrent keeps crashing regularly, I've not been able to find why.
OS: Debian 10.2 rtorrent version: 0.9.8 libtorrent: 0.13.8
1576725433 C Caught signal: 'Segmentation fault. ---DUMP--- Caught Segmentation fault, dumping stack: /usr/local/bin/rtorrent(+0x3a896) [0x55a16c33c896] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730) [0x7f84afef6730] /lib/x86_64-linux-gnu/libcurl.so.4(+0x38d1d) [0x7f84b00e1d1d] /lib/x86_64-linux-gnu/libcurl.so.4(curl_multi_socket_action+0x25) [0x7f84b00e1ff5] /usr/local/bin/rtorrent(+0x138849) [0x55a16c43a849] /usr/local/lib/libtorrent.so.21(_ZN7torrent9PollEPoll7performEv+0xca) [0x7f84affc91ea] /usr/local/lib/libtorrent.so.21(_ZN7torrent9PollEPoll7do_pollEli+0x70) [0x7f84affc9420] /usr/local/lib/libtorrent.so.21(_ZN7torrent11thread_base10event_loopEPS0_+0x110) [0x7f84b00023d0] /usr/local/bin/rtorrent(+0x39925) [0x55a16c33b925] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f84afa2409b] /usr/local/bin/rtorrent(+0x3a1ba) [0x55a16c33c1ba]Anyone here ever faced this issue ?
I got the same: 1577291634 C Caught signal: '娈甸敊璇? ---DUMP--- Caught Segmentation fault, dumping stack: /usr/local/bin/rtorrent(+0x3a896) [0x55a951c45896] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730) [0x7fbdddd28730] /usr/lib/x86_64-linux-gnu/libcurl.so.4(+0x38c39) [0x7fbddec1cc39] /usr/lib/x86_64-linux-gnu/libcurl.so.4(curl_multi_socket_action+0x25) [0x7fbddec1cff5] /usr/local/bin/rtorrent(+0x138849) [0x55a951d43849] /usr/local/lib/libtorrent.so.21(_ZN7torrent9PollEPoll7performEv+0xee) [0x7fbddeb0421e] /usr/local/lib/libtorrent.so.21(_ZN7torrent9PollEPoll7do_pollEli+0x70) [0x7fbddeb04430] /usr/local/lib/libtorrent.so.21(ZN7torrent11thread_base10event_loopEPS0+0x110) [0x7fbddeb3d3e0] /usr/local/bin/rtorrent(+0x39925) [0x55a951c44925] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7fbdddb7909b] /usr/local/bin/rtorrent(+0x3a1ba) [0x55a951c451ba]
---END---
I'm seeing similar crashes on a weekly basis on several FreeBSD 12.1-RELEASE-p1 GENERIC amd64 systems running rTorrent 0.9.8/0.13.8. All dependencies like cURL etc. are up to date with FreeBSD ports and have been rebuilt several times.
user@system: ~ % rtorrent Caught Segmentation fault, dumping stack: 0x285e1b <_ZTVN7torrent14resource_errorE+0x40403> at /usr/local/bin/rtorrent 0x8005e23c0 <_pthread_sigmask+0x530> at /lib/libthr.so.3 zsh: abort (core dumped) rtorrent
System 1:
GNU gdb (GDB) 8.3.1 [GDB v8.3.1 for FreeBSD]
...
This GDB was configured as "x86_64-portbld-freebsd12.1".
...
Reading symbols from rtorrent...
(No debugging symbols found in rtorrent)
[New LWP 100510]
[New LWP 100656]
[New LWP 100657]
Core was generated by `rtorrent'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00000008008f31ba in thr_kill () from /lib/libc.so.7
[Current thread is 1 (LWP 100510)]
(gdb) bt
#0 0x00000008008f31ba in thr_kill () from /lib/libc.so.7
#1 0x00000008008f15e4 in raise () from /lib/libc.so.7
#2 0x00000008008657e9 in abort () from /lib/libc.so.7
#3 0x0000000000285fda in ?? ()
#4 0x00000008005e23c0 in ?? () from /lib/libthr.so.3
#5 0x00000008005e198f in ?? () from /lib/libthr.so.3
#6
System 2:
GNU gdb (GDB) 8.3.1 [GDB v8.3.1 for FreeBSD]
...
This GDB was configured as "x86_64-portbld-freebsd12.1".
...
Reading symbols from rtorrent...
(No debugging symbols found in rtorrent)
[New LWP 100485]
[New LWP 100874]
[New LWP 100875]
Core was generated by `rtorrent'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00000008008f31ba in thr_kill () from /lib/libc.so.7
[Current thread is 1 (LWP 100485)]
(gdb) bt
#0 0x00000008008f31ba in thr_kill () from /lib/libc.so.7
#1 0x00000008008f15e4 in raise () from /lib/libc.so.7
#2 0x00000008008657e9 in abort () from /lib/libc.so.7
#3 0x0000000000285fda in ?? ()
#4 0x00000008005e23c0 in ?? () from /lib/libthr.so.3
#5 0x00000008005e198f in ?? () from /lib/libthr.so.3
#6
@TakerMc I had many crashes, too. Mine were related to DHT, so disabling it fixed the crashes for now. Maybe it's worth a try, just set dht.mode.set = disable in your config.
https://github.com/rakshasa/rtorrent/issues/914#issuecomment-534640711 is a good example how to get more hints. I also opened an issue about my problem, which seems libtorrent-related.
The crash reported by @TakerMc is most likely related to curl 7.64.0 shipped with Debian Buster. Upgrading to 7.67.0 (backported from Bullseye) seems to have fixed this particular crash on my system. Incidentally, this also fixed recurring SSL connect error failures.
I have the same problem.
Caught Segmentation fault, dumping stack:
rtorrent(+0x42cd7) [0x556f3f1f2cd7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x13510) [0x7f6fb9145510]
/lib/x86_64-linux-gnu/libcurl.so.4(+0x3e103) [0x7f6fb9ae2103]
/lib/x86_64-linux-gnu/libcurl.so.4(+0x3897a) [0x7f6fb9adc97a]
/lib/x86_64-linux-gnu/libcurl.so.4(curl_multi_socket_action+0x24) [0x7f6fb9adcb74]
rtorrent(+0x150901) [0x556f3f300901]
rtorrent(+0x1509c4) [0x556f3f3009c4]
rtorrent(+0x43a95) [0x556f3f1f3a95]
/lib/x86_64-linux-gnu/libtorrent.so.21(_ZN7torrent11thread_base10event_loopEPS0_+0x15d) [0x7f6fb9a030dd]
rtorrent(+0x41a4e) [0x556f3f1f1a4e]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f6fb8f98bbb]
rtorrent(+0x422da) [0x556f3f1f22da]
Aborted
rtorrent: 0.9.8 libtorrent: 0.13.8 libcurl: 7.67.0 OS: Debian Bullseye
I have the same problem.
Caught Segmentation fault, dumping stack: rtorrent(+0x42cd7) [0x556f3f1f2cd7] /lib/x86_64-linux-gnu/libpthread.so.0(+0x13510) [0x7f6fb9145510] /lib/x86_64-linux-gnu/libcurl.so.4(+0x3e103) [0x7f6fb9ae2103] /lib/x86_64-linux-gnu/libcurl.so.4(+0x3897a) [0x7f6fb9adc97a] /lib/x86_64-linux-gnu/libcurl.so.4(curl_multi_socket_action+0x24) [0x7f6fb9adcb74] rtorrent(+0x150901) [0x556f3f300901] rtorrent(+0x1509c4) [0x556f3f3009c4] rtorrent(+0x43a95) [0x556f3f1f3a95] /lib/x86_64-linux-gnu/libtorrent.so.21(_ZN7torrent11thread_base10event_loopEPS0_+0x15d) [0x7f6fb9a030dd] rtorrent(+0x41a4e) [0x556f3f1f1a4e] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f6fb8f98bbb] rtorrent(+0x422da) [0x556f3f1f22da] Abortedrtorrent: 0.9.8 libtorrent: 0.13.8 libcurl: 7.67.0 OS: Debian Bullseye
Update: I downgraded libcurl to 7.64.0 (from the Debian Buster repo) and the crashing appears to have gone away.
Same error as above:
1579144551 C Caught signal: 'Segmentation fault.
---DUMP---
Caught Segmentation fault, dumping stack:
rtorrent(+0x3a896) [0x563aafd6c896]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730) [0x7fca0ddc6730]
/usr/lib/x86_64-linux-gnu/libcurl.so.4(+0x38c39) [0x7fca0dfb1c39]
/usr/lib/x86_64-linux-gnu/libcurl.so.4(curl_multi_socket_action+0x25) [0x7fca0dfb1ff5]
rtorrent(+0x138849) [0x563aafe6a849]
/usr/local/lib/libtorrent.so.21(_ZN7torrent9PollEPoll7performEv+0xee) [0x7fca0de9920e]
/usr/local/lib/libtorrent.so.21(_ZN7torrent9PollEPoll7do_pollEli+0x70) [0x7fca0de99420]
/usr/local/lib/libtorrent.so.21(_ZN7torrent11thread_base10event_loopEPS0_+0x110) [0x7fca0ded23d0]
rtorrent(+0x39925) [0x563aafd6b925]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7fca0d8f409b]
rtorrent(+0x3a1ba) [0x563aafd6c1ba]
---END---
rtorrent: 0.9.8 libtorrent: 0.13.8 libcurl4: 7.64.0-4 OS: Debian Buster 10.2
Same for me . It happens on three different computers Debian 9 rtorrent 0.9.8 libtorrent 0.13.8 libcurl/7.52.1
1580785271 C Caught signal: 'Segmentation fault. ---DUMP--- Caught Segmentation fault, dumping stack: rtorrent(+0x15190) [0x4cc190] /lib/arm-linux-gnueabihf/libc.so.6(+0x29650) [0xb6ab4650] /usr/lib/libtorrent.so.21(+0x90458) [0xb6e57458] /usr/lib/libtorrent.so.21(_ZN7torrent9PollEPoll7performEv+0x89) [0xb6df84be] /usr/lib/libtorrent.so.21(_ZN7torrent9PollEPoll7do_pollExi+0x3f) [0xb6df8590] /usr/lib/libtorrent.so.21(ZN7torrent11thread_base10event_loopEPS0+0x11d) [0xb6e1e8be] rtorrent(+0x140e4) [0x4cb0e4] /lib/arm-linux-gnueabihf/libc.so.6(__libc_start_main+0x97) [0xb6aa5aac]
---END---
I have a fresh installation (today) where I migrated an old session with a lot of torrents. I am getting this segfault as well.
I currently have XMLRPC disabled. I played around with the logging/dbg stuff a lot, and I got this error which seems to indicate curl:
...
New Thread 0xad6ff220 (LWP 7360)]
[Thread 0xad6ff220 (LWP 7360) exited]
[New Thread 0xad6ff220 (LWP 7361)]
[Thread 0xad6ff220 (LWP 7361) exited]
4.4 [U 2/0] [D 0/0] [H 32/32] [S 93/96
Thread 1 "rtorrent main" received signal SIGSEGV, Segmentation fault.
0xb6ea6f50 in ?? () from /usr/lib/arm-linux-gnueabihf/libcurl.so.4
I also did a backtrace right after that error:
(gdb) bt
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x18:
#0 0xb6ea6f50 in ?? () from /usr/lib/arm-linux-gnueabihf/libcurl.so.4
Cannot access memory at address 0x18
After I did that, I went to double check my version numbers and post this. Curl displayed a mismatch, because I installed 7.68 from source but it was still getting the old (7.64) version of libcurl.
I actually wrote most of this several days ago, and only today resolved the libcurl issue. I had to search from and remove all libcurl packages shipped with my distro in order to get rtorrent to use the new version. Not sure why that is.
Anyway, I've been stable for a bit now, so I'm convinced my issue was due to a bad libcurl version, specifically 7.64.
I also fought this issue for several months last year, after migrating my rTorrent from an ancient Debian box to a new VM. I tried Debian 10 (Buster), Void Linux (both musl and glibc), Alpine Linux 3.9 and FreeBSD 12.0, but rTorrent would never run for more than 10 minutes without a cURL related segfault. I guess it occurs when one of the active trackers uses some non-standard combination of TLS settings, and perhaps only when the amount of torrents is above a certain limit, since this bug is so difficult to reproduce.
My solution was to setup a VM running Debian 9 (Stretch), which uses good old cURL 7.52.1. Now my rTorrent stays running for months on end. Debian 9 receives security updates until 2022, so for now it will do. rtorrent/libtorrent on Stretch is one version behind Buster (0.9.6/0.13.6 vs 0.9.7/0.13.7), but everything works and is rock stable.
Upgrade Debian packages solved my problem.
Env:
uname -a
Linux nuc 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) x86_64 GNU/Linux
cat /etc/debian_version
bullseye/sid
Upgrade:
sudo apt-get update
sudo apt-get upgrade
After:
find /usr -name '*libcurl*'
/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
/usr/lib/x86_64-linux-gnu/libcurl.so.4
/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.3
/usr/lib/x86_64-linux-gnu/libcurl.so.4.6.0
/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.6.0
/usr/share/lintian/overrides/libcurl3-gnutls
/usr/share/doc/libcurl4
/usr/share/doc/libcurl3-gnutls
sudo apt list --installed | grep curl
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
curl/testing,now 7.68.0-1 amd64 [installed]
libcurl3-gnutls/testing,now 7.68.0-1 amd64 [installed,automatic]
libcurl4/testing,now 7.68.0-1 amd64 [installed,automatic]
python3-pycurl/testing,now 7.43.0.2-1 amd64 [installed,automatic]
The problem started for me too today, without any change in the system / rtorrent settings.
I started with a new session folder, and the problem continue, so i assumed its not on rtorrent side. And that's not the libcurl problem in my case since my libcurl was last updated on 22 Feb.
After closing my rutorrent tab in firefox, rtorrent stopped crashing. Because i've changed some hidden firefox settings recently (but don't have time to find which one caused the problem), i created a new clean profile, and the segfault just stopped.
To be sure i relaunched my old profile, and rtorrent segfault immediatly.
started for me today aswell, no changes anywhere
rtorrent: 0.9.6 libtorrent: 0.13.6 libcurl4: 7.64.0-4 OS: Debian Buster 10
I can confirm @alswl (https://github.com/rakshasa/rtorrent/issues/944#issuecomment-592933284) answer. Upgrade to debian 11 (bullseye) solved the issue.
- rtorrent : 0.9.8
- libtorrent: 0.13.8
- libcurl4: 7.68.0-1
- OS : Debian Bullseye 11 / testing
I can confirm @alswl (#944 (comment)) answer. Upgrade to debian 11 (bullseye) solved the issue.
- rtorrent : 0.9.8
- libtorrent: 0.13.8
- libcurl4: 7.68.0-1
- OS : Debian Bullseye 11 / testing
Also worked for me !!
Anyone been able to fix this without upgrading to Bullseye? I attempted an upgrade to Bullseye on my Proxmox LXC, but it sadly failed to boot after, so I am looking for a simpler fix...
Anyone been able to fix this without upgrading to Bullseye? I attempted an upgrade to Bullseye on my Proxmox LXC, but it sadly failed to boot after, so I am looking for a simpler fix...
You could compile newer versions of cURL and rTorrent yourself, or find a pre-built statically linked binary using non-broken versions. However that it not an optimal solution since you wouldn't receive security fixes. The proper solution is definitely to upgrade to Bullseye. It wouldn't take that much work to set up a new VM and migrate your rTorrent to it. Install "rtorrent" using apt, copy over your config file + session dir, start it, and it will continue where it left off on your previous server.
You could also try to identify which tracker is triggering the crash, and stop using that until you're able to upgrade. Or install another torrent client on the server to use for that specific tracker.
Anyone been able to fix this without upgrading to Bullseye? I attempted an upgrade to Bullseye on my Proxmox LXC, but it sadly failed to boot after, so I am looking for a simpler fix...
You could compile newer versions of cURL and rTorrent yourself, or find a pre-built statically linked binary using non-broken versions. However that it not an optimal solution since you wouldn't receive security fixes. The proper solution is definitely to upgrade to Bullseye. It wouldn't take that much work to set up a new VM and migrate your rTorrent to it. Install "rtorrent" using apt, copy over your config file + session dir, start it, and it will continue where it left off on your previous server.
You could also try to identify which tracker is triggering the crash, and stop using that until you're able to upgrade. Or install another torrent client on the server to use for that specific tracker.
Thanks for the reply, I think I will indeed have to start with a fresh Bullseye LXC. It's just that I have a really fully customized Buster image with all my personal tweaks on it, only partially reproducible using Salt. But I think I'll go this route.
It's indeed one specific tracker that's causing this behavior, due to their use of Cloudflare (seeing from the error logs before the crashes). Have paused usage of that one right now.
Bug is back again since I migrated to debian 12 (bookworm).
/lib/x86_64-linux-gnu/libc.so.6(+0x3bfd0) [0x7f214e57efd0]
/lib/x86_64-linux-gnu/libcurl.so.4(+0x39c6c) [0x7f214eaffc6c]
/lib/x86_64-linux-gnu/libnghttp2.so.14(+0xb610) [0x7f214e51d610]
/lib/x86_64-linux-gnu/libnghttp2.so.14(+0xfc21) [0x7f214e521c21]
/lib/x86_64-linux-gnu/libnghttp2.so.14(nghttp2_session_send+0x69) [0x7f214e522ab9]
/lib/x86_64-linux-gnu/libcurl.so.4(+0x3a628) [0x7f214eb00628]
/lib/x86_64-linux-gnu/libcurl.so.4(+0x18519) [0x7f214eade519]
/lib/x86_64-linux-gnu/libcurl.so.4(+0x187bf) [0x7f214eade7bf]
/lib/x86_64-linux-gnu/libcurl.so.4(+0x4d5e3) [0x7f214eb135e3]
/lib/x86_64-linux-gnu/libcurl.so.4(+0x4f56e) [0x7f214eb1556e]
/lib/x86_64-linux-gnu/libcurl.so.4(+0x4ffdd) [0x7f214eb15fdd]
/lib/x86_64-linux-gnu/libcurl.so.4(curl_multi_socket_action+0x1b) [0x7f214eb1614b]
rtorrent(+0x14ac11) [0x55e61b698c11]
/usr/local/lib/libtorrent.so.21(_ZN7torrent9PollEPoll7performEv+0xa6) [0x7f214e9f33c6]
/usr/local/lib/libtorrent.so.21(_ZN7torrent9PollEPoll7do_pollEli+0x55) [0x7f214e9f34e5]
/usr/local/lib/libtorrent.so.21(_ZN7torrent11thread_base10event_loopEPS0_+0x123) [0x7f214ea26fd3]
rtorrent(+0x4145b) [0x55e61b58f45b]
/lib/x86_64-linux-gnu/libc.so.6(+0x271ca) [0x7f214e56a1ca]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7f214e56a285]
I tried to use a static version of curl 7.74, but it doesn't work.
Bug is back again since I migrated to debian 12 (bookworm).
I tried to use a static version of curl 7.74, but it doesn't work.
Same here. Were you able to fix it?
