2013-04-15 2 views
1

Segfault иногда возникает, когда я вызываю deadline_timer::async_wait по моему методу SendMessageAgain. Это может произойти одним из двух способов; Я включил обратные трассы ниже. Это кажется случайным, что заставляет меня думать, что какое-то условие гонки. У меня есть класс с объектом io_serviceioService, и несколько потоков, каждый из которых имеет таймеры, подключенные к ioService. Возможно, мне нужно заблокировать ioService перед вызовом async_wait? Я подумал, что это так.Segfault внутри boost :: asio :: deadline_timer :: async_wait

Возможно, это имеет какое-то отношение к тому, какой код прерывается, когда таймер гаснет. Каков оптимальный способ установки таймеров с соблюдением сроков, когда выполняется другой код?

код я использую в SendMessageAgain является

void Node::SendMessageAgain(unsigned long seqNum) { 
    // figure out if and what to send (using object fields) 
    if (should_send_again) { 
    Send(...); 
    timer->expires_from_now(INTERVAL); 
    timer->async_wait(bind(&Node::SendMessageAgain, this, seqNum)); 
    } 
} 
 
#0 0x08060609 in boost::asio::detail::deadline_timer_service<boost::asio::time_traits<boost::posix_time::ptime> >::async_wait<boost::_bi::bind_t<void, boost::_mfi::mf1<void, Node, unsigned long>, boost::_bi::list2<boost::_bi::value<Node*>, boost::_bi::value<unsigned long> > > > (this=0x14, impl=..., handler=...) 
    at /usr/include/boost/asio/detail/deadline_timer_service.hpp:170 
#1 0x0805e2e7 in boost::asio::deadline_timer_service<boost::posix_time::ptime, boost::asio::time_traits<boost::posix_time::ptime> >::async_wait<boost::_bi::bind_t<void, boost::_mfi::mf1<void, Node, unsigned long>, boost::_bi::list2<boost::_bi::value<Node*>, boost::_bi::value<unsigned long> > > > (this=0x0, impl=..., 
    handler=...) at /usr/include/boost/asio/deadline_timer_service.hpp:135 
#2 0x0805bcbb in boost::asio::basic_deadline_timer<boost::posix_time::ptime, boost::asio::time_traits<boost::posix_time::ptime>, boost::asio::deadline_timer_service<boost::posix_time::ptime, boost::asio::time_traits<boost::posix_time::ptime> > >::async_wait<boost::_bi::bind_t<void, boost::_mfi::mf1<void, Node, unsigned long>, boost::_bi::list2<boost::_bi::value<Node*>, boost::_bi::value<unsigned long> > > > (this=0x807fc50, handler=...) 
    at /usr/include/boost/asio/basic_deadline_timer.hpp:435 
#3 0x080555a2 in Node::SendMessageAgain (this=0xbfffefdc, seqNum=8) 
    at node.cpp:147 
 
#0 __pthread_mutex_lock (mutex=0x2f200c4) at pthread_mutex_lock.c:50 
#1 0x08056c79 in boost::asio::detail::posix_mutex::lock (this=0x2f200c4) 
    at /usr/include/boost/asio/detail/posix_mutex.hpp:52 
#2 0x0805a036 in boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>::scoped_lock (this=0xbfffeb04, m=...) 
    at /usr/include/boost/asio/detail/scoped_lock.hpp:36 
#3 0x08061dd0 in boost::asio::detail::epoll_reactor::schedule_timer<boost::asio::time_traits<boost::posix_time::ptime> > (this=0x2f200ac, queue=..., 
    time=..., timer=..., op=0x807fca0) 
    at /usr/include/boost/asio/detail/impl/epoll_reactor.hpp:43 
#4 0x0806063a in boost::asio::detail::deadline_timer_service<boost::asio::time_traits<boost::posix_time::ptime> >::async_wait<boost::_bi::bind_t<void, boost::_mfi::mf1<void, Node, unsigned long>, boost::_bi::list2<boost::_bi::value<Node*>, boost::_bi::value<unsigned long> > > > (this=0xb6b005fc, impl=..., 
    handler=...) 
    at /usr/include/boost/asio/detail/deadline_timer_service.hpp:170 
#5 0x0805e2fd in boost::asio::deadline_timer_service<boost::posix_time::ptime, boost::asio::time_traits<boost::posix_time::ptime> >::async_wait<boost::_bi::bind_t<void, boost::_mfi::mf1<void, Node, unsigned long>, boost::_bi::list2<boost::_bi::value<Node*>, boost::_bi::value<unsigned long> > > > (this=0xb6b005e8, 
    impl=..., handler=...) 
    at /usr/include/boost/asio/deadline_timer_service.hpp:135 
#6 0x0805bcd1 in boost::asio::basic_deadline_timer<boost::posix_time::ptime, bo---Type <return> to continue, or q <return> to quit--- 
ost::asio::time_traits<boost::posix_time::ptime>, boost::asio::deadline_timer_service<boost::posix_time::ptime, boost::asio::time_traits<boost::posix_time::ptime> > >::async_wait<boost::_bi::bind_t<void, boost::_mfi::mf1<void, Node, unsigned long>, boost::_bi::list2<boost::_bi::value<Node*>, boost::_bi::value<unsigned long> > > > (this=0xb6b005a0, handler=...) 
    at /usr/include/boost/asio/basic_deadline_timer.hpp:435 
#7 0x080555a7 in Node::SendMessageAgain (this=0xbfffefdc, seqNum=9) 
    at node.cpp:148 
+1

Возможно ли, что ваш «узел» выходит за пределы области действия, пока асинхронная задача все еще находится на рассмотрении? – Chad

+0

Я так не думаю. В 'main' я делаю' Node n; n.Create() '. 'Create' порождает пару потоков, а затем вызывает' io_service :: run() ', что в моем случае является неретеррантным, так как у меня есть периодический таймер, и я никогда его не отменю. Может быть проблематично, что другие потоки создают таймеры в одном и том же «io_service»? – Nick

+0

это звучит как проблема с жизненным циклом объекта, после [sscce] (http://sscce.org) –

ответ

2

Хорошо, это исправлено. Как предположил Сэм, это был вопрос жизни объекта, хотя и не с Node. У меня был таймер в объекте, принадлежащем Node. В моем коде было состояние гонки, в котором я сбросил таймер за пределами критической секции, и его владелец был уничтожен между окончанием критического раздела и сбросом таймера. Я просто расширил критический раздел и зафиксировал его.

Я не знаю, почему проявлялась выдаёт ошибку сегментации так далеко вниз в async_wait, хотя, так как обратный вызов (и связанный с this указатель) принадлежал к Node, которая до сих пор существовала.

0

Bad:

timer->async_wait(bind(&Node::SendMessageAgain, this, seqNum, _1)); 

Хорошо:

timer->async_wait(bind(&Node::SendMessageAgain, shared_from_this(), seqNum, _1)); 

Наличие узла расширить enable_shared_from_this

class Node : public boost::enable_shared_from_this<Node> 

Это может решить проблему, если это вызвано ваш узел разрушается во время обратного вызова по-прежнему запланирован на него.

+1

Узел не уничтожается до выхода программы. – Nick

+1

с использованием голого указателя вполне приемлемо, если объект переживает io_service –

Смежные вопросы