Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regular rtorrent crashes because of DHT #209

Open
espressoelf opened this issue Jan 7, 2020 · 2 comments
Open

Regular rtorrent crashes because of DHT #209

espressoelf opened this issue Jan 7, 2020 · 2 comments

Comments

@espressoelf
Copy link

After many crashes, I found another issue where gdb was mentioned and did the same to provide a better stack trace:

0x00007ffff7e3b4e8 in torrent::DhtServer::find_node_next (this=0x6b8ad0,
    transaction=0x3b54960) at dht_transaction.h:341
341     dht_transaction.h: No such file or directory.
Missing separate debuginfos, use: [...]
(gdb) bt
#0  0x00007ffff7e3b4e8 in torrent::DhtServer::find_node_next (this=0x6b8ad0,
    transaction=0x3b54960) at dht_transaction.h:341
#1  0x00007ffff7e3bcb6 in torrent::DhtServer::parse_find_node_reply (
    this=0x6b8ad0, transaction=0x3b54960, nodes=...) at dht_server.cc:466
#2  0x00007ffff7e3be85 in torrent::DhtServer::process_response (this=0x6b8ad0,
    id=..., sa=0x7fffffffd440, response=...) at dht_transaction.h:446
#3  0x00007ffff7e3c008 in torrent::DhtServer::event_read (this=0x6b8ad0)
    at dht_server.cc:793
#4  0x00007ffff7deb38a in torrent::PollEPoll::perform (
    this=this@entry=0x62a690) at poll_epoll.cc:185
#5  0x00007ffff7deb485 in torrent::PollEPoll::do_poll (this=0x62a690,
    timeout_usec=<optimized out>, flags=<optimized out>) at poll_epoll.cc:224
#6  0x00007ffff7e1efa3 in torrent::thread_base::event_loop (
    thread=<optimized out>) at thread_base.cc:174
#7  0x0000000000435255 in main (argc=1, argv=0x7fffffffe358) at main.cc:490

Disabling DHT fixed the crashes, but I'd like to use it again. I compiled xmlrpc-c (advanced, v1.57.0), libtorrent (v0.13.8) and rtorrent (v0.9.8) like it's described here, except that I had to run export PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig before calling ./configure.

Any guess what could be the problem or a hint what I could do to provide more information?

@slingamn
Copy link

slingamn commented Apr 2, 2020

I've got that backtrace, plus this one which appears to be a double-free:

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007f4fdb819801 in __GI_abort () at abort.c:79
#2  0x000055ee54a63f78 in do_panic (signum=11) at main.cc:632
#3  <signal handler called>
#4  0x000055ee6e42c910 in ?? ()
#5  0x00007f4fdc42d4ce in torrent::DhtTransactionSearch::~DhtTransactionSearch (this=0x55ee6d29da60, __in_chrg=<optimized out>) at dht_transaction.cc:309
#6  0x00007f4fdc42b243 in torrent::DhtTransactionFindNode::~DhtTransactionFindNode (this=0x55ee6d29da60, __in_chrg=<optimized out>) at dht_transaction.h:367
#7  torrent::DhtTransactionFindNode::~DhtTransactionFindNode (this=0x55ee6d29da60, __in_chrg=<optimized out>) at dht_transaction.h:367
#8  0x00007f4fdc426c58 in torrent::DhtServer::failed_transaction (this=this@entry=0x55ee55cd0e80, itr={first = 194669371216363729, second = 0x55ee6d29da60}, quick=quick@entry=false) at dht_server.cc:684
#9  0x00007f4fdc42722d in torrent::DhtServer::receive_timeout (this=0x55ee55cd0e80) at dht_server.cc:939
#10 0x00007f4fdc3b7811 in std::function<void ()>::operator()() const (this=<optimized out>) at /usr/include/c++/7/bits/std_function.h:706
#11 torrent::thread_main::call_events (this=<optimized out>) at thread_main.cc:82
#12 0x00007f4fdc407e8c in torrent::thread_base::event_loop (thread=0x55ee55c4f740) at thread_base.cc:141
#13 0x000055ee54a62a82 in main (argc=5, argv=0x7ffd79277a28) at main.cc:495

#166 has this valgrind output from a couple years ago: https://gist.github.com/slingamn/578793a4b7eeffd0a564daa707a2ac1b

jesec added a commit to jesec/libtorrent that referenced this issue May 23, 2022
Use-after-free occurs when the transaction ID is exhausted.

As the ID only has one char, on an instance with many torrents, it
is easy to exhaust the ID space, so that new transactions have to
be discarded.

However, The new transaction could be associated with an ongoing
DhtSearch that does not expect transaction to be freed.

Follow up of "dht_server: fix potential use-after-free" (1418bf9),
properly fix the issue and deal with memory leak with this method.

Bug: rakshasa/libtorrent#166, rakshasa/libtorrent#209, rakshasa/libtorrent#944
@trancephorm
Copy link

Any chance for fixing this? DHT is very very needed thing in rtorrent, it's a shame such a good client crashes. Lot of serious pro seeders rely on it. I even want to pay to whoever fixes and pushes the changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants