August 2018 - Boost-users - lists.boost.org

[boost.interprocess] Construct boost::basic_string with managed_shared_memory as memory soure crash.
by Zhiming Wang 03 Aug '18

03 Aug '18

Hi, I am using boost 1.65.1 interprocess lib, and tried to construct a string that is safe to store in a managed_shared_memory. Types are defined as below: using namespace boost::interprocess; using ShmSegment_t = boost::interprocess::managed_shared_memory; using SegmentMgr_t = boost::interprocess::managed_shared_memory::segment_manager; template <typename T> using Allocator_t = boost::interprocess::allocator<T, SegmentMgr_t>; using String_t = boost::interprocess::basic_string<char, std::char_traits<char>, Allocator_t<char>>; Code in problem is as below: using namespace boost::interprocess; ShmSegment_t segment(open_or_create, "Test", 1L << 31); const std::string stdStr("std_str"); String_t ipcStr( stdStr.c_str(), segment.get_segment_manager()); *// oops, crashed! * Crash backtrace is as below: #0 0x00007ffff7ab735c in boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>::get_size (this=0x441f0ff40024) at /usr/include/boost/interprocess/mem_algo/rbtree_best_fit.hpp:593 #1 0x00007ffff7ab157a in boost::interprocess::segment_manager_base<boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0u l> >::get_size (this=0x441f0ff40024) at /usr/include/boost/interprocess/segment_manager.hpp:113 #2 0x00007ffff7ab002d in boost::interprocess::allocator<char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> >::max_size (this=0x7fffeeffbe80) at /usr/include/boost/interprocess/allocators/allocator.hpp:164 #3 0x00007ffff7aaf34d in boost::container::allocator_traits<boost::interprocess::allocator<char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_fa mily, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::priv_max_size (a=...) at /usr/include/boost/container/allocator_traits.hpp:397 #4 boost::container::allocator_traits<boost::interprocess::allocator<char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interproc ess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::max_size (a=...) at /usr/include/boost/container/allocator_traits.hpp:331 #5 boost::container::container_detail::basic_string_base<boost::interprocess::allocator<char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_famil y, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::max_size (this=0x7fffeeffbe80) at /usr/include/boost/container/string.hpp:354 #6 0x00007ffff7aae68a in boost::container::basic_string<char, std::char_traits<char>, boost::interprocess::allocator<char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boo st::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::max_size (this=0x7fffeeffbe80) at /usr/include/boost/container/string.hpp:1080 #7 0x00007ffff7aadb7a in boost::container::basic_string<char, std::char_traits<char>, boost::interprocess::allocator<char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boo st::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::priv_reserve (this=0x7fffeeffbe80, res_arg=21, null_terminate=true) at /usr/include/boost/container/string.hpp:2777 #8 0x00007ffff7aad62a in boost::container::basic_string<char, std::char_traits<char>, boost::interprocess::allocator<char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boo st::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::reserve (this=0x7fffeeffbe80, res_arg=21) at /usr/include/boost/container/string.hpp:1141 #9 0x00007ffff7aacbdf in boost::container::basic_string<char, std::char_traits<char>, boost::interprocess::allocator<char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boo st::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::assign (this=0x7fffeeffbe80, first=0x7fff5c000d60 "std_str", last=0x7fff5c000d75 "") at /usr/include/boost/container/string.hpp:1494 #10 0x00007ffff7aac719 in boost::container::basic_string<char, std::char_traits<char>, boost::interprocess::allocator<char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boo st::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::basic_string (this=0x7fffeeffbe80, s=0x7fff5c000d60 "std_str", a=...) at /usr/include/boost/container/string.hpp:741 I tried "p m_header" within GDB at /usr/include/boost/interprocess/mem_algo/rbtree_best_fit.hpp:593, and GDB told me the memory is not accessable. What's worse is that the issue seems not happening in very code path, that's it sometimes works and sometimes fails. Any insight is appreciated. Thanks.

3 2

Re: [Boost-users] ASIO: custom service which works with spawn/yield
by Vinnie Falco 03 Aug '18

03 Aug '18

On Thu, Aug 2, 2018 at 1:02 PM, Richard Hodges <hodges.r(a)gmail.com> wrote: > I think it's worth mentioning that although your code is very well written > and laid out, the horrid internals of asio mean that only ultra-experts can > read it. It really doesn't 'flow'. > > Surely something can be done (in asio and networking TS) in terms of > providing a cleaner, more logical interface for io_object and service > developers? I have thought about this for a few years and even made efforts to provide algorithms and types to make authoring code easier, but they were not successful. I don't think a "grand unifying theory" exists. However, I also think there is a LOT of room for documentation to grow and mature, and there is opportunity for authors to develop strong, well commented examples (something I strive for in Beast). With Networking TS as part of C++20 (or later), at last there will be one correct interface for doing asynchrony. This will incentivize book publishers and library authors to focus specifically on this networking interface to provide educational resources. In my Cppcon 2018 presentation I am also dedicating a couple of slides with guidance on how to learn Asio effectively and write correct programs. Regards

1 0

Serialization and class versioning
by tim＠raisedbar.net 02 Aug '18

02 Aug '18

Hi, I have an application that uses serialization for data storage/retrieval, based on Boost 1.67.0. I've implemented class versioning as per: https://www.boost.org/doc/libs/1_67_0/libs/serialization/doc/tutorial.html#v ersioning The overall archive stores a number of sub-classes, nested within the XML. However, I get a run-time exception thrown that I can't catch when one of my sub-classes (DisplayDefinition) returns from being read in. A bit of debugging found that the problem was caused by the class version number having a value of 0, whilst the file being read had a version number of 3 for the class in question. Here's the bit of the class responsible for the archiving: class DisplayDefinition: public MessageDefinition { ... private: friend std::ostream & operator<<(std::ostream &os, const DisplayDefinition &DD); friend std::istream & operator>>(std::istream &is, const DisplayDefinition &DD); friend class boost::serialization::access; template<class Archive> void serialize(Archive & myArchive, const unsigned int version) { try { const char * cLabelTag = "Label"; myArchive & boost::serialization::make_nvp( cLabelTag, wstrLabel); const char * cAddressBytesTag = "SysExAddressBytes"; myArchive & boost::serialization::make_nvp( cAddressBytesTag, vSysExAddressBytes); const char * cActionsTag = "Actions"; myArchive & boost::serialization::make_nvp( cActionsTag, myActions); const char * cStatesTag = "StateNames"; myArchive & boost::serialization::make_nvp( cStatesTag, StateLabels); const char * cLineCountTag = "LineCount"; myArchive & boost::serialization::make_nvp( cLineCountTag, nDisplayLineCount); const char * cLineLengthTag = "LineLength"; myArchive & boost::serialization::make_nvp( cLineLengthTag, nDisplayLength); const char * cStripCountTag = "StripCount"; myArchive & boost::serialization::make_nvp( cStripCountTag, nStripCount); const char * cIsLEDLampTag = "LEDLamp"; myArchive & boost::serialization::make_nvp( cIsLEDLampTag, blnIsLEDLamp); const char * cTranslationTag = "TranslationID"; myArchive & boost::serialization::make_nvp( cTranslationTag, strTranslationID); const char * cCursorOffsetTag = "CursorOffset"; myArchive & boost::serialization::make_nvp( cCursorOffsetTag, nCursorOffset); if(version > 0) { const char * cCursorFromLeftTag = "CursorFromLeft"; myArchive & boost::serialization::make_nvp( cCursorFromLeftTag, blnCursorFromLeft); } if(version > 1) { const char * cUniCodeTag = "Unicode"; myArchive & boost::serialization::make_nvp( cUniCodeTag, blnIsUniCode); } if(version > 2) { const char * cLinkedHashTag = "LinkedTo"; myArchive & boost::serialization::make_nvp( cLinkedHashTag, strLinkedDisplayHash); } } // end try catch (...) { throw ID_LOAD_DATA_EXCEPTION; } // end catch } ... }; // end of class definition BOOST_CLASS_VERSION(DisplayDefinition, 3); I'm clueless as to why the BOOST_CLASS_VERSION macro doesn't seem to be setting the version number correctly. Can anybody advise me, please? Best wishes. Tim Burgess Raised Bar Ltd. E: <mailto:tim@raisedbar.net> tim(a)raisedbar.net M: +44 (0)7989 486976

2 3

ASIO: custom service which works with spawn/yield
by Cristian Morales Vega 02 Aug '18

02 Aug '18

Hi, I have implemented a custom service using Boost 1.67 which works mostly OK, but I have noticed it always returns success when using spawn/yield. The following simplified sample shows the problem: ------------------------------------------------ #include <boost/asio.hpp> #include <boost/asio/spawn.hpp> #include <boost/beast/core/bind_handler.hpp> #include <iostream> class Service : public boost::asio::io_context::service { public: static boost::asio::io_context::id id; typedef int implementation_type; Service(boost::asio::io_context &io_context) : boost::asio::io_context::service(io_context) {} void construct(implementation_type &) {} void destroy(implementation_type &) {} }; boost::asio::io_context::id Service::id; template <typename Service> class BasicObject : protected boost::asio::basic_io_object<Service> { public: explicit BasicObject(boost::asio::io_context &io_context) : boost::asio::basic_io_object<Service>(io_context) {} template <typename ConnectHandler> auto async_method(ConnectHandler &&handler) { BOOST_ASIO_CONNECT_HANDLER_CHECK(ConnectHandler, handler) typeCheck; boost::asio::async_completion<ConnectHandler, void(const boost::system::error_code &)> init(handler); boost::system::error_code ec = boost::asio::error::already_started; boost::asio::post( boost::beast::bind_handler(std::move(init.completion_handler), std::move(ec))); return init.result.get(); } }; int main() { boost::asio::io_context ioContext; BasicObject<Service> myObject(ioContext); #if 1 boost::asio::spawn(ioContext, [&](boost::asio::yield_context yield) { boost::system::error_code ec; myObject.async_method(yield[ec]); std::clog << ec << std::endl; }); #else myObject.async_method([](const boost::system::error_code &ec) { std::clog << ec << std::endl; }); #endif ioContext.run(); return 0; } ------------------------------------------------ The version not using spawn prints "system:114", the one using spawn prints "system:0". What am I doing wrong? Thanks.

6 18

[release] 1.68.0 closed for release
by Marshall Clow 02 Aug '18

02 Aug '18

The master branch is now closed for all changes except by permission. The commit-bot isn't running on master, so the super project will need to be manually updated for any changes. If all goes well, the release candidate should be out tomorrow. Thanks, -- The Boost Release Team

1 0

[GIL] Boost gil and constexpr
by Eloi Du Bois 01 Aug '18

01 Aug '18

Hi, It seems that the development on boost::gil is starting again on boost 1.68, and I have an advise: I think boost::gil would strongly benefits on using constexpr in the code, it would make a lot of things statically resolved. There's a huge work to put this everywhere, but I think it would be nice. Just an idea. Thanks,

3 3