id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc 3670,endless loop in dev_poll_reactor on Solaris,dirkmoermans@…,chris_kohlhoff,"The following example-program exposes high CPU-usage on Solaris 10, despite not doing anything useful while sleeping. Top reports a CPU-usage between 10 and 25% on a 4 CPU-box. In order to reproduce, a TCP-server has to be listening on the configured host-port. {{{ #include #include #include #include #include // g++ -pthread -g2 -I/opt/include/boost-1_41 -L/opt/lib -lboost_system-gcc43-mt-1_41 -lboost_thread-gcc43-mt-1_41 -lsocket -lnsl f.cc // this program exposes a high CPU usage when run on solaris 10 using the dev_poll_reactor (the default). const char HOSTNAME[]=""localhost""; const char PORT[]=""46000""; const int THREADS=3; const int SOCKETS=10; const int LOOPS=10; const int SLEEPTIME=10; // seconds void handler(const boost::system::error_code& error) { std::cout << ""socket connected '"" << error << ""'"" << std::endl; } int main() { using namespace boost::asio::ip; boost::asio::io_service service; boost::asio::io_service::work work(service); boost::thread_group pool; for(int i=0;i > Sockets; Sockets sockets; for(int j=0;j (new boost::asio::ip::tcp::socket(service,boost::asio::ip::tcp::v4()))); } for(Sockets::iterator si=sockets.begin(); si!=sockets.end(); ++si) { (*si)->async_connect(*result,handler); } sleep(SLEEPTIME); } } }}} The cause seems to be an endless loop in dev_poll_reactor::run The problematic stacktrace: {{{ #0 0xffffffff7e0d3a50 in _write () from /lib/64/libc.so.1 #1 0xffffffff7e0c4394 in write () from /lib/64/libc.so.1 #2 0x0000000100024258 in boost::asio::detail::dev_poll_reactor::run (this=0x100131e80, block=true) at /opt/gnu4u_prince_ext/include/boost-1_41/boost/asio/detail/dev_poll_reactor.hpp:467 #3 0x0000000100024850 in boost::asio::detail::task_io_service >::do_one (this=0x10012f090, lock=@0xffffffff7d0fba28, this_idle_thread=0xffffffff7d0fba08, ec=@0xffffffff7d0fbb18) at /opt/gnu4u_prince_ext/include/boost-1_41/boost/asio/detail/task_io_service.hpp:260 #4 0x0000000100024adc in boost::asio::detail::task_io_service >::run (this=0x10012f090, ec=@0xffffffff7d0fbb18) at /opt/gnu4u_prince_ext/include/boost-1_41/boost/asio/detail/task_io_service.hpp:103 #5 0x0000000100024c34 in boost::asio::io_service::run (this=0xffffffff7ffff028) at /opt/gnu4u_prince_ext/include/boost-1_41/boost/asio/impl/io_service.ipp:58 #6 0x000000010000d33c in boost::_mfi::mf0::operator() (this=0x100131b20, t=@0xffffffff7ffff028) at /opt/gnu4u_prince_ext/include/boost-1_41/boost/bind/mem_fn_template.hpp:68 #7 0x000000010000d400 in boost::_bi::list1 >::operator(), boost::_bi::list0> (this=0x100131b30, f=@0x100131b20, a=@0xffffffff7d0fbd9f) at /opt/gnu4u_prince_ext/include/boost-1_41/boost/bind/bind.hpp:236 #8 0x000000010000d460 in boost::_bi::bind_t, boost::_bi::list1 > >::operator() (this=0x100131b20) at /opt/gnu4u_prince_ext/include/boost-1_41/boost/bind/bind_template.hpp:20 #9 0x000000010000d48c in boost::detail::thread_data, boost::_bi::list1 > > >::run ( this=0x100131a50) at /opt/gnu4u_prince_ext/include/boost-1_41/boost/thread/detail/thread.hpp:56 #10 0xffffffff7f00ba30 in thread_proxy () from /opt/gnu4u_prince_ext/lib/libboost_thread-gcc43-mt-1_41.so.1.41.0 #11 0xffffffff7e0d24e0 in _lwp_start () from /lib/64/libc.so.1 #12 0xffffffff7e0d24e0 in _lwp_start () from /lib/64/libc.so.1 }}} the local variables just after the write: {{{ (gdb) info locals ev = {fd = 13, events = 24, revents = 0} result = 8 more_reads = false more_writes = false more_except = false ec = {m_val = 0, m_cat = 0xffffffff7f4033a8} descriptor = 13 i = 0 lock = { = {}, mutex_ = @0x100131ea8, locked_ = true} events_size = 0 timeout = -1 events = {{fd = 13, events = 28, revents = 4}, {fd = 14, events = 28, revents = 4}, {fd = 16, events = 28, revents = 4}, {fd = 0, events = 0, revents = 0} } dp = {dp_fds = 0xffffffff7d0fb2d0, dp_nfds = 128, dp_timeout = -1} num_events = 3 sb = { = {}, blocked_ = true, old_mask_ = {__sigbits = {0, 0, 0, 0}}} }}} The program works fine on Linux and works fine on Solaris when compiled with the flag -DBOOST_ASIO_DISABLE_DEV_POLL. I am pretty sure that this behaviour has been present since at least boost 1.37.",Bugs,closed,Boost 1.42.0,asio,Boost 1.41.0,Regression,fixed,,