Bug#934747: /usr/bin/rtorrent: rtorrent crashes with error "Could not create download: Info hash already used by another torrent."

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#934747: /usr/bin/rtorrent: rtorrent crashes with error "Could not create download: Info hash already used by another torrent."

tnemeth (Bugzilla)
Package: rtorrent
Version: 0.9.7-1
Severity: grave
File: /usr/bin/rtorrent
Tags: upstream
Justification: renders package unusable

Hi,

for several weeks now, rtorrent crashes when I start it (no changes have
been made to either its configuration nor its torrents list for many
month).

Here is the log it produces:

--------8<--------8<--------8<--------8<--------8<--------
1565781738 N rtorrent main: Starting thread.
1565781738 N rtorrent scgi: Starting thread.
1565781747 E Could not create download: Info hash already used by another torrent.
1565781747 E Could not create download: Info hash already used by another torrent.
1565781747 E Could not create download: Info hash already used by another torrent.
1565781747 E Could not create download: Info hash already used by another torrent.
1565781747 E Could not create download: Info hash already used by another torrent.
1565781747 E Could not create download: Info hash already used by another torrent.
1565781747 E Could not create download: Info hash already used by another torrent.
1565781747 E Could not create download: Info hash already used by another torrent.
1565781747 E Could not create download: Info hash already used by another torrent.
1565781771 C Caught signal: 'Erreur de segmentation.
---DUMP---
Caught Segmentation fault, dumping stack:
rtorrent(+0x11e59) [0x4afe59]
linux-gate.so.1(__kernel_sigreturn+0) [0xb7f92d7c]
/usr/lib/i386-linux-gnu/libcurl.so.4(+0x31640) [0xb7e69640]
/usr/lib/i386-linux-gnu/libcurl.so.4(+0x328f2) [0xb7e6a8f2]
/usr/lib/i386-linux-gnu/libcurl.so.4(+0x2f7f7) [0xb7e677f7]
/usr/lib/i386-linux-gnu/libcurl.so.4(+0x30612) [0xb7e68612]
/usr/lib/i386-linux-gnu/libcurl.so.4(+0x30951) [0xb7e68951]
/usr/lib/i386-linux-gnu/libcurl.so.4(+0x33d5c) [0xb7e6bd5c]
/usr/lib/i386-linux-gnu/libcurl.so.4(+0x35205) [0xb7e6d205]
/usr/lib/i386-linux-gnu/libcurl.so.4(curl_multi_socket_action+0x2f) [0xb7e6d3af]
rtorrent(+0xda370) [0x578370]
rtorrent(+0xda68c) [0x57868c]
rtorrent(+0x1341b) [0x4b141b]
/usr/lib/i386-linux-gnu/libtorrent.so.20(_ZN7torrent11thread_base10event_loopEPS0_+0x229) [0xb7d8ec89]
rtorrent(+0x10b7b) [0x4aeb7b]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0xb77e7b41]
rtorrent(+0x1173b) [0x4af73b]

---END---
--------8<--------8<--------8<--------8<--------8<--------

I can't figure which torrent causes that message but it should not make
the program to segfault...


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-5-686-pae (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rtorrent depends on:
ii  libc6              2.28-10
ii  libcppunit-1.14-0  1.14.0-4
ii  libcurl4           7.65.1-1
ii  libgcc1            1:9.1.0-10
ii  libncursesw6       6.1+20190803-1
ii  libstdc++6         9.1.0-10
ii  libtinfo6          6.1+20190803-1
ii  libtorrent20       0.13.7-1
ii  libxmlrpc-core-c3  1.33.14-8+b1

rtorrent recommends no packages.

Versions of packages rtorrent suggests:
pn  screen | dtach  <none>

-- no debconf information

Reply | Threaded
Open this post in threaded view
|

Bug#934747: /usr/bin/rtorrent: rtorrent crashes with error "Could not create download: Info hash already used by another torrent."

Bernhard Übelacker-3
Control: reassign -1 libcurl4 7.65.1-1
Control: affects -1 + rtorrent
Control: tags -1 + upstream fixed-upstream
Control: fixed -1 7.65.3-1


Dear Maintainer,
I just tried to find some more information from the given backtrace.

That I guess would translate to something like below [1],
if it would have been done with a debugger and debug symbols.

These stack looks in the last frames similar to these shown in [2] and [3].
And these seem to get fixed upstream in commit [4]
that is in curl-7_65_2 and above.

So in theory the libcurl4 7.65.3-1 from unstable
might not show these segfaults.

Kind regards,
Bernhard


[1]
rtorrent(+0x11e59) [0x4afe59]                                                  | 0x00411e54 0x00411e59 in do_panic(int) at main.cc:596:       int stackSize = backtrace(stackPtrs, 20);
linux-gate.so.1(__kernel_sigreturn+0) [0xb7f92d7c]                             |            0xb7fd4d7c <__kernel_sigreturn>
libcurl.so.4(+0x31640) [0xb7e69640]                                            |            0xb7eab640 in sh_delentry at multi.c:253:         dta->sh_entry = NULL;
libcurl.so.4(+0x328f2) [0xb7e6a8f2]                                            | 0xb7eac8ed 0xb7eac8f2 in Curl_multi_closed at multi.c:2397
libcurl.so.4(+0x2f7f7) [0xb7e677f7]                                            | 0xb7ea97f2 0xb7ea97f7 in Curl_closesocket at connect.c:1347
libcurl.so.4(+0x30612) [0xb7e68612]                                            | 0xb7eaa60d 0xb7eaa612 in trynextip at connect.c:606
libcurl.so.4(+0x30951) [0xb7e68951]                                            | 0xb7eaa94c 0xb7eaa951 in Curl_is_connected at connect.c:861
libcurl.so.4(+0x33d5c) [0xb7e6bd5c]                                            | 0xb7eadd57 0xb7eadd5c in multi_runsingle at multi.c:1509
libcurl.so.4(+0x35205) [0xb7e6d205]                                            | 0xb7eaf200 0xb7eaf205 in multi_socket at multi.c:2564
libcurl.so.4(curl_multi_socket_action+0x2f) [0xb7e6d3af]                       | 0xb7eaf3aa 0xb7eaf3af in curl_multi_socket_action at multi.c:2677
rtorrent(+0xda370) [0x578370]                                                  | 0x004da36b 0x004da370 in core::CurlStack::receive_action(core::CurlSocket*, int) at curl_stack.cc:95
rtorrent(+0xda68c) [0x57868c]                                                  | 0x004da687 0x004da68c in core::CurlStack::receive_timeout() at curl_stack.cc:171
rtorrent(+0x1341b) [0x4b141b]                                                  | 0x00413418 0x0041341b in std::function<void ()>::operator()() const at /usr/include/c++/7/bits/std_function.h:706
libtorrent.so.20(_ZN7torrent11thread_base10event_loopEPS0_+0x229) [0xb7d8ec89] | 0xb7dd0c83 0xb7dd0c89 in std::function<void ()>::operator()() const at /usr/include/c++/7/bits/std_function.h:706
rtorrent(+0x10b7b) [0x4aeb7b]                                                  | 0x00410b76 0x00410b7b in main(int, char**) at main.cc:480:         torrent::thread_base::event_loop(torrent::main_thread());
libc.so.6(__libc_start_main+0xf1) [0xb77e7b41]                                 | 0xb7829b3d 0xb7829b41 in __libc_start_main at ../csu/libc-start.c:308
rtorrent(+0x1173b) [0x4af73b]                                                  | 0x00411736 0x0041173b <_start+44>


[2] https://github.com/curl/curl/issues/3995
[3] https://github.com/curl/curl/issues/4057
[4] https://github.com/curl/curl/commit/4981fae7f158152fca01bddb042231f9f8343d58

debugging.txt (9K) Download Attachment