On Tue, Jun 8, 2010 at 4:25 AM, Jorge Moraleda <jorge.moral...@gmail.com> wrote: > > I compile example/http/server2 from boost (1.43) asio library using: > g++ -l boost_thread -l boost_system > /opt/boost/boost/doc/html/boost_asio/example/http/server2/*cpp > > When I run it using valgrind drd (svn r11158) using: > > valgrind --tool=drd ./a.out 127.0.0.1 31175 4 /tmp > > The output is clean until the first time I connect to the server (by > typing http://localhost:31175/anything on a browser) at which point > several warnings pop up as shown below. Are these false alarms, or > actual concurrency bugs in boost asio or the example code? > > Thank you, > > Jorge > > ==15768== drd, a thread error detector > ==15768== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche. > ==15768== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright > info > ==15768== Command: ./a.out 127.0.0.1 31175 8 /tmp > ==15768== > ==15768== Thread 4: > ==15768== Conflicting load by thread 4 at 0x061875f0 size 8 > ==15768== at 0x40DB72: > boost::asio::detail::op_queue<boost::asio::detail::reactor_op>::front() > (in /tmp/a.out) > ==15768== by 0x417974: > boost::asio::detail::epoll_reactor::run(bool, > boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation<boost::asio::detail::epoll_reactor> > >&) (in /tmp/a.out) > [ ... ]
This looks like a race on descriptor_state::op_queue_, so I had a look at the following source code: http://www.boost.org/doc/libs/1_43_0/boost/asio/detail/epoll_reactor.hpp. My comments on this source code are as follows: * The comments at the bottom of class epoll_reactor say that any access of registered_descriptors_ should be protected by registered_descriptors_mutex_. However, the method shutdown_service() modifies the container registered_descriptors_ but doesn't lock registered_descriptors_mutex_. * The method epoll_reactor::register_descriptor() modifies its second argument (descriptor_data) such that it points to the newly created descriptor_state object. All data members of the struct descriptor_state are public, but all accesses must be guarded by a lock on descriptor_state::mutex_. So all callers of register_descriptor() must be checked in order to verify whether or not there are any thread-unsafe accesses of descriptor_state::op_queue_ or descriptor_state::shutdown_. Personally I never recommended such a class design. * While all accesses of the members of struct descriptor_state should be protected by locking descriptor_state::mutex_, no lock is held on this last mutex by register_descriptor() when it sets descriptor_data::shutdown_ nor by shutdown_service() while it modifies descriptor_state::op_queue_ and descriptor_state::shutdown_. The former is easy to fix: move the "descriptor_data->shutdown_ = false" statement to somewhere before the epoll_ctl() system call. Does one of the above scenarios explain the race report you have observed ? Bart. ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
