Re: stalls with concurrent host name resolvers

On Nov 19, 2006, at 22:10, Christopher Kohlhoff wrote:
> Hmm, same as me. I managed to get it to happen very
> occasionally, but when I tried to debug it using gdb it locked
> up my ssh session. It makes me think that it's something to do
> with the OS, but I can't say for certain. Or perhaps some asio
> code is assuming that an OS function is thread safe when it
> isn't. If you're able to get a call stack when the thing
> deadlocks that would be most useful.

Ok, it happens every time for me. I did a testrun with 10 io_services  
(and afaik that means 10 host resolver threads). Most host resolver  
threads appeared to be blocked at this point:

#0      0x9000ab48 in mach_msg_trap
#1      0x9000aa9c in mach_msg
#2      0x9002beb0 in _lookup_all_secure
#3      0x9002bdbc in _lookup_all
#4      0x9005a564 in lu_gethostbyname
#5      0x90078324 in getipnodebyname
#6      0x0019dc50 in asio::detail::socket_ops::gethostbyname at  
posix_event.hpp:671
#7      0x001a327c in asio::detail::socket_ops::getaddrinfo_emulation at  
socket_ops.hpp:1155
#8      0x001a372c in asio::detail::socket_ops::getaddrinfo at  
socket_ops.hpp:1443
#9      0x001d338c in  
asio::detail::resolver_service<asio::ip::tcp>::resolve_query_handler<boo 
st::_bi::bind_t<void, boost::_mfi::mf2<void,  
libtorrent::http_tracker_connection, asio::error_code const&,  
asio::ip::basic_resolver_iterator<asio::ip::tcp> >,  
boost::_bi::list3<boost::_bi::value<boost::intrusive_ptr<libtorrent::htt 
p_tracker_connection> >, boost::arg<1>, boost::arg<2> > > >::operator 
() at resolver_service.hpp:184
#10     0x001d359c in  
asio::asio_handler_invoke<asio::detail::resolver_service<asio::ip::tcp>: 
:resolve_query_handler<boost::_bi::bind_t<void,  
boost::_mfi::mf2<void, libtorrent::http_tracker_connection,  
asio::error_code const&,  
asio::ip::basic_resolver_iterator<asio::ip::tcp> >,  
boost::_bi::list3<boost::_bi::value<boost::intrusive_ptr<libtorrent::htt 
p_tracker_connection> >, boost::arg<1>, boost::arg<2> > > > > at  
handler_invoke_hook.hpp:62
...

The debugger didn't break immediately, so it's possible that the  
"deadlock" was just released when gdb managed to stop the execution.  
But on the other hand, all host resolver threads that wasn't idling,  
was had this same call stack.


--
Arvid Norberg



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV