- Boost - lists.boost.org

Spam in ticket 865
by Jeremiah Willcock 08 Jun '10

08 Jun '10

There is a spam comment in <URL:https://svn.boost.org/trac/boost/ticket/865> that should be removed. -- Jeremiah Willcock

1 0

[asio] Race conditions detected with valgrind drd in example/http/server2
by Jorge Moraleda 08 Jun '10

08 Jun '10

When testing boost.asio (example/http/server2) for race conditions using valgrind drd, some errors are reported right after the first connection to the server is made. I am using Valgrind-3.6.0.SVN and gcc version 4.4.4 (Debian 4.4.4-4). This is an up to date Debian sid 64 bit system. To reproduce: g++ -l boost_thread -l boost_system /opt/boost/boost/doc/html/boost_asio/example/http/server2/*cpp valgrind --tool=drd ./a.out 127.0.0.1 31174 8 /tmp While it is running type "http://localhost:31174/main.cpp" in your browser (where main.cpp is a file in /tmp). Then several race conditions occur. These are the valgrind error messages: ==7737== drd, a thread error detector ==7737== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche. ==7737== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info ==7737== Command: ./a.out 127.0.0.1 31174 8 /tmp ==7737== ==7737== Thread 4: ==7737== Conflicting load by thread 4 at 0x061875f0 size 8 ==7737== at 0x40DB72: boost::asio::detail::op_queue<boost::asio::detail::reactor_op>::front() (in /tmp/a.out) ==7737== 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) ==7737== by 0x41C809: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::do_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::idle_thread_info*) (in /tmp/a.out) ==7737== by 0x41A026: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::run(boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x417D26: boost::asio::io_service::run() (in /tmp/a.out) ==7737== by 0x430358: unsigned long boost::_mfi::mf0<unsigned long, boost::asio::io_service>::call<boost::shared_ptr<boost::asio::io_service> >(boost::shared_ptr<boost::asio::io_service>&, void const*) const (in /tmp/a.out) ==7737== by 0x42FF74: unsigned long boost::_mfi::mf0<unsigned long, boost::asio::io_service>::operator()<boost::shared_ptr<boost::asio::io_service> >(boost::shared_ptr<boost::asio::io_service>&) const (in /tmp/a.out) ==7737== by 0x42FE1E: unsigned long boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::asio::io_service> > >::operator()<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list0>(boost::_bi::type<unsigned long>, boost::_mfi::mf0<unsigned long, boost::asio::io_service>&, boost::_bi::list0&, long) (in /tmp/a.out) ==7737== by 0x42FD66: boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::asio::io_service> > > >::operator()() (in /tmp/a.out) ==7737== by 0x42EE79: boost::detail::thread_data<boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::asio::io_service> > > > >::run() (in /tmp/a.out) ==7737== by 0x4E41F5F: thread_proxy (in /usr/local/lib/libboost_thread.so.1.43.0) ==7737== by 0x4C2EA60: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272) ==7737== Address 0x61875f0 is at offset 80 from 0x61875a0. Allocation context: ==7737== at 0x4C26FD1: operator new(unsigned long) (vg_replace_malloc.c:261) ==7737== by 0x43BDC8: __gnu_cxx::new_allocator<std::_List_node<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> > >::allocate(unsigned long, void const*) (in /tmp/a.out) ==7737== by 0x43B72D: std::_List_base<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state>, std::allocator<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> > >::_M_get_node() (in /tmp/a.out) ==7737== by 0x43AD64: std::list<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state>, std::allocator<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> > >::_M_create_node(std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> const&) (in /tmp/a.out) ==7737== by 0x43A0FC: std::list<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state>, std::allocator<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> > >::insert(std::_List_iterator<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> >, std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> const&) (in /tmp/a.out) ==7737== by 0x439A77: boost::asio::detail::hash_map<int, boost::asio::detail::epoll_reactor::descriptor_state>::values_insert(std::_List_iterator<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> >, std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> const&) (in /tmp/a.out) ==7737== by 0x438B60: boost::asio::detail::hash_map<int, boost::asio::detail::epoll_reactor::descriptor_state>::insert(std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> const&) (in /tmp/a.out) ==7737== by 0x43811B: boost::asio::detail::epoll_reactor::register_descriptor(int, boost::asio::detail::epoll_reactor::descriptor_state*&) (in /tmp/a.out) ==7737== by 0x43DE25: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D954: boost::asio::stream_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D689: boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >::assign(boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D274: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::accept_op_base<boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >::do_perform(boost::asio::detail::reactor_op*) (in /tmp/a.out) ==7737== Other segment start (thread 3) ==7737== at 0x4C2F283: pthread_mutex_lock (drd_pthread_intercepts.c:578) ==7737== by 0x40AC2B: boost::asio::detail::posix_mutex::lock() (in /tmp/a.out) ==7737== by 0x40D4CF: boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>::scoped_lock(boost::asio::detail::posix_mutex&) (in /tmp/a.out) ==7737== by 0x4380D4: boost::asio::detail::epoll_reactor::register_descriptor(int, boost::asio::detail::epoll_reactor::descriptor_state*&) (in /tmp/a.out) ==7737== by 0x43DE25: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D954: boost::asio::stream_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D689: boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >::assign(boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D274: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::accept_op_base<boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >::do_perform(boost::asio::detail::reactor_op*) (in /tmp/a.out) ==7737== by 0x40AF7A: boost::asio::detail::reactor_op::perform() (in /tmp/a.out) ==7737== by 0x41798B: 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) ==7737== by 0x41C809: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::do_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::idle_thread_info*) (in /tmp/a.out) ==7737== by 0x41A026: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::run(boost::system::error_code&) (in /tmp/a.out) ==7737== Other segment end (thread 3) ==7737== at 0x4C2FE7F: pthread_mutex_unlock (drd_pthread_intercepts.c:631) ==7737== by 0x40AC45: boost::asio::detail::posix_mutex::unlock() (in /tmp/a.out) ==7737== by 0x40D500: boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>::~scoped_lock() (in /tmp/a.out) ==7737== by 0x438273: boost::asio::detail::epoll_reactor::register_descriptor(int, boost::asio::detail::epoll_reactor::descriptor_state*&) (in /tmp/a.out) ==7737== by 0x43DE25: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D954: boost::asio::stream_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D689: boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >::assign(boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D274: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::accept_op_base<boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >::do_perform(boost::asio::detail::reactor_op*) (in /tmp/a.out) ==7737== by 0x40AF7A: boost::asio::detail::reactor_op::perform() (in /tmp/a.out) ==7737== by 0x41798B: 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) ==7737== by 0x41C809: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::do_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::idle_thread_info*) (in /tmp/a.out) ==7737== by 0x41A026: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::run(boost::system::error_code&) (in /tmp/a.out) ==7737== ==7737== Thread 3: ==7737== Probably a race condition: condition variable 0x8583c40 has been signaled but the associated mutex 0x61820f8 is not locked by the signalling thread. ==7737== at 0x4C283F9: pthread_cond_signal@* (drd_pthread_intercepts.c:736) ==7737== by 0x4119FE: void boost::asio::detail::posix_event::signal_and_unlock<boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex> >(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&) (in /tmp/a.out) ==7737== by 0x4108F2: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::wake_one_idle_thread_and_unlock(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&) (in /tmp/a.out) ==7737== by 0x40F1C2: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::wake_one_thread_and_unlock(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&) (in /tmp/a.out) ==7737== by 0x40DA56: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::init_task() (in /tmp/a.out) ==7737== by 0x40B941: boost::asio::detail::epoll_reactor::init_task() (in /tmp/a.out) ==7737== by 0x4148D8: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::reactive_socket_service(boost::asio::io_service&) (in /tmp/a.out) ==7737== by 0x414035: boost::asio::stream_socket_service<boost::asio::ip::tcp>::stream_socket_service(boost::asio::io_service&) (in /tmp/a.out) ==7737== by 0x413893: boost::asio::io_service::service* boost::asio::detail::service_registry::create<boost::asio::stream_socket_service<boost::asio::ip::tcp> >(boost::asio::io_service&) (in /tmp/a.out) ==7737== by 0x40ADB8: boost::asio::detail::service_registry::do_use_service(boost::asio::io_service::service::key const&, boost::asio::io_service::service* (*)(boost::asio::io_service&)) (in /tmp/a.out) ==7737== by 0x412B7E: boost::asio::stream_socket_service<boost::asio::ip::tcp>& boost::asio::detail::service_registry::use_service<boost::asio::stream_socket_service<boost::asio::ip::tcp> >() (in /tmp/a.out) ==7737== by 0x411B3A: boost::asio::stream_socket_service<boost::asio::ip::tcp>& boost::asio::use_service<boost::asio::stream_socket_service<boost::asio::ip::tcp> >(boost::asio::io_service&) (in /tmp/a.out) ==7737== cond 0x8583c40 was first observed at: ==7737== at 0x4C27C59: pthread_cond_init@* (drd_pthread_intercepts.c:652) ==7737== by 0x417573: boost::asio::detail::posix_event::posix_event() (in /tmp/a.out) ==7737== by 0x419F07: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::idle_thread_info::idle_thread_info() (in /tmp/a.out) ==7737== by 0x419FBC: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::run(boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x417D26: boost::asio::io_service::run() (in /tmp/a.out) ==7737== by 0x430358: unsigned long boost::_mfi::mf0<unsigned long, boost::asio::io_service>::call<boost::shared_ptr<boost::asio::io_service> >(boost::shared_ptr<boost::asio::io_service>&, void const*) const (in /tmp/a.out) ==7737== by 0x42FF74: unsigned long boost::_mfi::mf0<unsigned long, boost::asio::io_service>::operator()<boost::shared_ptr<boost::asio::io_service> >(boost::shared_ptr<boost::asio::io_service>&) const (in /tmp/a.out) ==7737== by 0x42FE1E: unsigned long boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::asio::io_service> > >::operator()<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list0>(boost::_bi::type<unsigned long>, boost::_mfi::mf0<unsigned long, boost::asio::io_service>&, boost::_bi::list0&, long) (in /tmp/a.out) ==7737== by 0x42FD66: boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::asio::io_service> > > >::operator()() (in /tmp/a.out) ==7737== by 0x42EE79: boost::detail::thread_data<boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::asio::io_service> > > > >::run() (in /tmp/a.out) ==7737== by 0x4E41F5F: thread_proxy (in /usr/local/lib/libboost_thread.so.1.43.0) ==7737== by 0x4C2EA60: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272) ==7737== mutex 0x61820f8 was first observed at: ==7737== at 0x4C2EC6B: pthread_mutex_init (drd_pthread_intercepts.c:537) ==7737== by 0x40AB63: boost::asio::detail::posix_mutex::posix_mutex() (in /tmp/a.out) ==7737== by 0x410B72: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::task_io_service(boost::asio::io_service&) (in /tmp/a.out) ==7737== by 0x40F679: boost::asio::io_service::service* boost::asio::detail::service_registry::create<boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor> >(boost::asio::io_service&) (in /tmp/a.out) ==7737== by 0x40ADB8: boost::asio::detail::service_registry::do_use_service(boost::asio::io_service::service::key const&, boost::asio::io_service::service* (*)(boost::asio::io_service&)) (in /tmp/a.out) ==7737== by 0x40DDDE: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>& boost::asio::detail::service_registry::use_service<boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor> >() (in /tmp/a.out) ==7737== by 0x417C48: boost::asio::io_service::io_service() (in /tmp/a.out) ==7737== by 0x416921: http::server2::io_service_pool::io_service_pool(unsigned long) (in /tmp/a.out) ==7737== by 0x437816: http::server2::server::server(std::string const&, std::string const&, std::string const&, unsigned long) (in /tmp/a.out) ==7737== by 0x43064D: main (in /tmp/a.out) ==7737== ^C==7737== ==7737== For counts of detected and suppressed errors, rerun with: -v ==7737== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 225 from 194)

1 1

[endian] views and conversions
by vicente.botet 08 Jun '10

08 Jun '10

Hi, I have pushed the endian typed approach a little more. Given an C/C++ builtin integer, we can see it as an endian with a given endianness using a cast or view operation. This operation doesn't do any conversion when its parameter is a fundamental (integer) type, but just let the user states that the integer stored in the variable has been stored with the given endianness. int b; Let me say that b contains an integer with big endian format (this has been done by reading from an external device, e.g.) The following expression as<big>(i) or endian_cast<big>(i) will see the i storage as a big endian integer holder. Now we can convert from big to native as follows int n; as<native>(n) = as<big>(b); as<endianness>(x) can be implemented as a function that return a endian reference to an integer with a specific endianness. Let me call this class endian_view. endian_view will define the assignment operator so the there is a conversion when both sides have the same endianness. In place conversion can be done as follows: as<native>(b) = as<big>(b); In order to support the in place version the assignement operator on endian_views, needs to check in addition if the reference integer is the same. But this check could be inefficient when we are converting a whole structure. The same operation can be overloaded for endian_views and do a in_place conversion in this case as<native>(as<big>(b)); can be read as: make the integer b (which is formatted with big endian format) have a native endian format. Just some more thougths that can grow on the endian forest. Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

1 0

[msm] Nested submachines and explicit state entry
by Christophe Henry 08 Jun '10

08 Jun '10

Hi Michael, >As already stated in the documentation it is possible to have explicit >state entry into another submachine within a state machine. > >Is there a possibility to have a state machine, which has another >submachine with explicit state entry and that submachine has another >submachine with an initial transition. >I put that together in a picture and attached it. I hope then it gets >clearer what I want to do. >The picture shows just a simplified version of the overall state machine >and I discarded some other states, transitions and orthogonal regions. Starts becoming an interesting case ;-) Yes it should work. I tested with the same depth-level without any problem. What is not supported yet would be if your explicit entry was going into a substate of a submachine of a submachine, meaning you can only "cross" one submachine boundary. So your example is ok. >How do I have to declare the transition table and states in that case? A transition table is always declared inside a state machine, after the states have been declared. In my examples I always declare states inside the front-end but it is only for readability. In your case, you could declare the SM1 front-end, then inside its declaration add the one for RunningStateMachine, then inside RunningStateMachine the one for Inner1 and Inner2. After Inner1 and Inner2, the table for RunningStateMachine, then the table for SM1. something like: struct SM1_... { struct RunningStateMachine_... { struct Inner1_...; typedef msm::back::state_machine<Inner1_> Inner1; ... // add RunningStateMachine table }; typedef msm::back::state_machine<RunningStateMachine_> RunningStateMachine; // add SM1 table }; typedef msm::back::state_machine<SM1_> SM1; >Are there any restrictions regarding nested depth? Not in the library. I see just 2: - your patience while compiling - your compiler. At some point, it will probably get pissed off ;-) Regards, Christophe

2 2

Bug sprint daily update for Tuesday, June 8th
by Marshall Clow 08 Jun '10

08 Jun '10

As of 0800 Pacific time today, we had 938 open trac tickets. That is down by 20 from yesterday, and 51 since the start of the bug sprint. Total ticket counts: Saturday 989 Sunday 988 Monday 958 Tuesday 938 Great work, everyone! Activity summary for yesterday: New tickets: 4 Modified: 31 Closed: 27 Reopened: 2 Today, rather than the summary totals for yesterday, I have deltas; changes in the totals. If you'ld like to see the totals, they are available online at: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (All changes are since the start of the bug sprint; 0800 PDT Saturday June 5th) Changed totals by library: None -17 thread -16 website -10 units -3 Building Boost -2 random -2 GIL -1 Regression Testing -1 asio -1 date_time -1 filesystem -1 function -1 fusion -1 iterator -1 lexical_cast -1 mpi -1 mpl -1 regex -1 spirit -1 circular_buffer 1 foreach 1 program_options 1 serialization 1 utility 1 Documentation 2 graph 2 build 4 Changed totals by author: <none> -20 anthonyw -15 grafik -9 dave -2 dgregor -2 matthiasschabel -2 agurtovoy -1 az_sw_dude -1 bemandawes -1 bschaeling -1 chris_kohlhoff -1 danieljames -1 djowel -1 dlwalker -1 hkaiser -1 hljin -1 johnmaddock -1 nasonov -1 no-maintainer -1 speedsnail -1 steven_watanabe -1 danielw 1 eric_niebler 1 jano_gaspar 1 matias 1 ramey 1 witt 1 asutton 2 vladimir_prus 7 Changed totals by category: Bugs -37 Feature Requests -7 Patches -3 Tasks -3 -- Marshall

1 0

Re: [boost] Review of a safer memory management approach for C++
by Bartlett, Roscoe A 08 Jun '10

08 Jun '10

Mathias, > ------------------------------ > > Message: 19 > Date: Mon, 07 Jun 2010 15:43:18 +0100 > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++? > Message-ID: <huj0io$6iu$1(a)dough.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Bartlett, Roscoe A wrote: > > > I am fine with the language allowing for undefined behavior. Clearly > if you want the highest performance, you have to turn off array-bounds > checking, for instance, which allows for undefined behavior. What I > am not okay with is people writing programs that expose that undefined > behavior, especially w.r.t. to usage of memory. Every computational > scientist has had the experience of writing code that appeared to work > just fine on their main development platform but when they took to over > to another machine for a "production" run on a large (expensive) MPP to > run on 1000 processors, it segfaulted after having run for 45 minutes > and lost everything. This happens all the time with current CSE > software written in C, C++, and even Fortran. This is bad on many > levels. > > > > Are you suggesting that people should write programs that rely on > undefined behavior or are you just saying that you don't think it > should be eliminated from the language? > > From my experience, the best tool to identify and eliminate undefined > behaviour due to bad memory access is valgrind. > > I found it more practical and catching more errors than any > library-level tool. [Bartlett, Roscoe A] Tools like valgrind and purify are very helpful but are not nearly sufficient as described in Section 3.2 (and other sections) in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf Have other people had similar experiences with valgrind and purify to what I describe in Sectioin 3.2 in the above document? If valgrind and purify can pin-point memory errors so effectively, then why does it sometimes take nearly a week to track down certain types of memory errors in C++ (I have heard of such stories)? My record is most likely about three days to track down a single memory error (including using valgrind and purify for all the glues that I can get, less they segfaulted themselves of course which sometimes they do). In the process of tracking down and diagnosing some of these memory errors, I have had to apply all of my PhD-level problem solving and research skills and in the end I could not write a research paper to describe the wonderful problem-solving research-quality work that I did. What a waste of time and effort; very frustrating. I know many people that I work with that have had similar experiences. These types of experiences have lead many C++ teams to code C++ with a (justified but unfortunate) paranoia about the use of memory in C++ that has all kinds of bad consequences (see Section 1 in the above document for some of the consequences). Come one, at least some people on this mail list must have had similar nightmare experiences in trying to track down and diagnose hard memory misuse errors in C++ that took days of effort to resolve (even with the help of tools like valgrind and purify). And again, tools like valgrind and purify will *never* catch semantic misuse of memory (i.e. allocating a big chunk of memory and then breaking it up to be used to construct different objects and array of objects). The Teuchos MM classes will catch most semantic misuse of memory in a way that no tool like valgrind and purify every can (because they don't know the context of your program, they only know that any read/writes in a big block of memory that you allocated look okay). I think this is a big deal in catching hard-to-find defects that are not (technically speaking) memory misuse defects but are program defects none the less. Cheers, - Ross

6 9

[msm] Nested submachines and explicit state entry
by Michael.Herchel＠rohde-schwarz.com 08 Jun '10

08 Jun '10

Hi, As already stated in the documentation it is possible to have explicit state entry into another submachine within a state machine. Is there a possibility to have a state machine, which has another submachine with explicit state entry and that submachine has another submachine with an initial transition. I put that together in a picture and attached it. I hope then it gets clearer what I want to do. The picture shows just a simplified version of the overall state machine and I discarded some other states, transitions and orthogonal regions. How do I have to declare the transition table and states in that case? Are there any restrictions regarding nested depth? Best Regards, Michael

1 0

boost::thread compiler error on SUN CC 5.9
by Urs Stotz 08 Jun '10

08 Jun '10

boost::thread give a compile error on SUN CC 5.9: /opt/SUNWspro/bin/CC +d -library=stlport4 -library=stlport4 -xcode=pic32 -erroff=wvarhidemem,hidevf,hidevfinvb -errtags=yes -features=tmplife -features=tmplrefstatic -g -mt -erroff=%none -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -I"." -c -o "bin.v2/libs/thread/build/sun-5.9/debug/stdlib-sun-stlport/threading-multi/pthread/thread.o" "libs/thread/src/pthread/thread.cpp" "libs/thread/src/pthread/thread.cpp", line 77: Error, badbinaryop: The operation "boost::shared_ptr<boost::detail::tss_cleanup_function> && void*" is illegal. "libs/thread/src/pthread/thread.cpp", line 588: Error, badbinaryop: The operation "boost::shared_ptr<boost::detail::tss_cleanup_function> || void*" is illegal. 2 Error(s) detected. make: *** [thread.o] Error 2 with this small patch it will compile: --- boost_1_42_0.org/libs/thread/src/pthread/thread.cpp 2009-10-19 11:18:13.000000000 +0200 +++ boost_1_42_0/libs/thread/src/pthread/thread.cpp 2010-02-10 13:48:25.037748000 +0100 @@ -74,7 +74,7 @@ namespace boost { current=next; ++next; - if(current->second.func && current->second.value) + if(current->second.func && (current->second.value != 0)) { (*current->second.func)(current->second.value); } @@ -585,7 +585,7 @@ namespace boost { (*current_node->func)(current_node->value); } - if(func || tss_data) + if(func || (tss_data != 0) ) { current_node->func=func; current_node->value=tss_data;

3 2

SPAM in trac
by Steven Watanabe 08 Jun '10

08 Jun '10

AMDG I just saw some spam here: https://svn.boost.org/trac/boost/ticket/1338 In Christ, Steven Watanabe

3 3

asio loopback behavior, windows vs. linux
by Adam Crain 08 Jun '10

08 Jun '10

There’s an interesting behavioral difference between how the loopback works with ASIO on windows/linux. I have constructed a test that talks to an echo server across the loopback. The test steps are: 1) Open the socket using run_one(), verifying it is open 2) Start an async read 3) Start an async write 4) Call run_one, then verify the write succeeds 5) Call run_one, then verify that the data you write is received 6) Goto step 2 some number of times since the behavior is non-determinsitic One windows, this seems to consistently fail within the first 100 iterations, because on occasional you get the read callback with echoed data before the write success comes back!!!! This seems crazy that another process answers you before the OS/ASIO has even told you the write was successful. On Linux I have not been able to make this happen even with 10K’s of iterations. I can only assume that: 1) This can actually happen with Windows loopback + thread scheduling and my assumption that write callbacks will always occur before response data is invalid 2) There is a bug in the windows impl of ASIO that makes this possible. If anyone can shed some light on this I’d really appreciate it. I have code that wants to step through a series of states, and it makes things a lot more complicated if I can’t assume that the write callback will always occur before data received that’s a response to what I sent. Thanks! Adam Adam Crain Manager of R&D Green Energy Corp. 919-428-1002

2 1