Ticket #1272 (closed defect: fixed)

Opened 2 years ago

Last modified 2 weeks ago

rtorrent: priority_queue_insert(...) received a bad timer.

Reported by: josef Owned by: rakshasa
Priority: normal Milestone:
Component: libtorrent Version:
Severity: normal Keywords:
Cc:

Description

Problem occurs reproducibly when I force a manual hash-check on a torrent. In my case it had nothing completed, this may or may not make a difference. I also disabled all trackers and the download never successfully contacted a tracker, but it still shouldn't crash when completing the hash check.

#0  std::logic_error (this=0x8250fe0, msg=0x8175a60 "priority_queue_insert(...) received a bad timer.") at /usr/include/c++/4.1.0/stdexcept:61
#1  0x0807e131 in rak::priority_queue_insert (queue=0x81bcf7c, item=0x84fb718, t={m_time = 0}) at ../../rak/priority_queue_default.h:103
#2  0x08149a17 in torrent::TrackerManager::send_later (this=0x84fb6e8) at tracker_manager.cc:118
#3  0x080ad64d in core::DownloadList::resume (this=0x81c0728, download=0x85cc6d0, flags=-1) at download_list.cc:418
#4  0x080b0303 in core::DownloadList::hash_done (this=0x81c0728, download=0x85cc6d0) at download_list.cc:526
#5  0x080b0c4b in sigc::internal::slot_call0<sigc::bind_functor<-1, sigc::bound_mem_functor1<void, core::DownloadList, core::Download*>, core::Download*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>, void>::call_it (rep=0x85cc928)
    at /opt/gnome/include/sigc++-2.0/sigc++/functors/mem_fun.h:1851
#6  0x0813a896 in torrent::DownloadWrapper::receive_initial_hash (this=0x85c5fe8) at /opt/gnome/include/sigc++-2.0/sigc++/signal.h:544
#7  0x08104584 in torrent::perform () at ../../rak/functional_fun.h:102
#8  0x080c115d in core::PollManagerEPoll::poll (this=0x81c50d8, timeout={m_time = 1000}) at poll_manager_epoll.cc:111
#9  0x0807fd21 in main (argc=5, argv=0xbf88d584) at main.cc:286

Also the tracker list data:

(gdb) p *m_control
$2 = {<std::vector<torrent::Tracker*,std::allocator<torrent::Tracker*> >> = {<std::_Vector_base<torrent::Tracker*,std::allocator<torrent::Tracker*> >> = {
      _M_impl = {<std::allocator<torrent::Tracker*>> = {<__gnu_cxx::new_allocator<torrent::Tracker*>> = {<No data fields>}, <No data fields>},
 _M_start = 0x853b0d0, _M_finish = 0x853b0d8, _M_end_of_storage = 0x853b0d8}}, <No data fields>}, m_manager = 0x84fb6e8, 
  m_info = 0x85c61b0, m_state = 2, m_key = 2128065279, m_numwant = -1, m_timeLastConnection = 0, m_itr = {_M_current = 0x853b0d0}}

Seems the problem is that m_timeLastConnection = 0.

Attachments

tracker_timer_fix.diff (0.9 KB) - added by josef 22 months ago.
fix for tracker timer crash

Change History

Changed 22 months ago by gerd@hoerst.net

any news about that ? I got this also with last release....

ciao gerd

Changed 22 months ago by josef

This patch should fix it.

Changed 22 months ago by josef

fix for tracker timer crash

Changed 20 months ago by rakshasa

  • status changed from new to closed
  • resolution set to fixed

Changed 3 weeks ago by osakechan@gmail.com

Just got this error with rtorrent 0.8.2 on 64bit Karmic.... Has this patch been built into newer releases or will I need to patch myself?

Changed 2 weeks ago by anonymous

Why ask when you can just look it up?

  • bug fixed 20 months ago (see above)
  • rtorrent 0.8.2 released May 2008 = 22 months ago (see Changelog)

Assuming there are no time machines involved, the answer is obvious.

Add/Change #1272 (rtorrent: priority_queue_insert(...) received a bad timer.)

Author


E-mail address and user name can be saved in the Preferences.


Action
as closed
Next status will be 'reopened'
 
Note: See TracTickets for help on using tickets.