October 2021 - Boost-users - lists.preview.boost.org

Clarification on statechart post_event vs process_event within react()
by John McCabe 10 Jan '22

10 Jan '22

Hi, Apologies if this has already been answered/clarified, but my search of the internet to try to get a definitive answer, at least one I recognised as being definitive, was unsuccessful. Below I have posted some source code, based on the stopwatch example from the tutorial, but using an 'external' object to delegate the actual handling of event stuff to and using the state, rather than simple_state base class, and some other tweaks. This is a cut down version of something that someone I work with has devised, but I just wanted to get a clear answer on whether process_event() should be getting called in cases like this. I think it probably should not since, in the code below, you change state (with a state object's destructor being executed) whilst you're executing that state's react(EvStartStop) function. If someone can confirm this is the correct interpretation that would be very much appreciated. Any questions, feel free to ask (BTW - I'm compiling for C++17) John PS - In case it's of any use, the output from running this code is: ------ Entered Active Entered Stopped Stopped - payload2 m_charValue: a Exited ~Stopped <<<--- This is the bit I don't like the look of because... Entered Running Active - payload2 m_charValue: a <<<--- ... this happens from the forward_event() call payload1 value1: 20 payload1 value2: 200.2 Exited ~Running Entered Stopped Exiting Program Exited ~Stopped Exited ~Active ------ If I swap the //*** comments to the doProcess() lines instead of doPost(), the output seems more sensible ------ Entered Active Entered Stopped Stopped - payload2 m_charValue: a Exited ~Stopped Entered Running Active - payload2 m_charValue: a payload1 value1: 20 payload1 value2: 200.2 Exited ~Running Entered Stopped Exiting Program Exited ~Stopped Exited ~Active ------ ========== code =========== #include <boost/statechart/event.hpp> #include <boost/statechart/state_machine.hpp> #include <boost/statechart/state.hpp> #include <boost/statechart/transition.hpp> #include <boost/statechart/custom_reaction.hpp> #include <boost/mpl/list.hpp> #include <iostream> #include <string> namespace sc = boost::statechart; namespace mpl = boost::mpl; // Forward declare a handler 'class' that's going to have activity delegated to it struct Handler; // Normal example start/stop and reset events struct EvStartStop : sc::event<EvStartStop> {}; struct EvReset : sc::event<EvReset> {}; // A couple of events that carry data with them struct EvPayload1 : sc::event<EvPayload1> { EvPayload1(int value1, double value2) : m_value1 { value1 }, m_value2 { value2 } {}; int m_value1 { 0 }; double m_value2 { 0.0 }; }; struct EvPayload2 : sc::event<EvPayload2> { EvPayload2(const char& charValue) : m_charValue { charValue } {}; char m_charValue { false }; }; // Back to the example bits struct Active; struct StopWatch : sc::state_machine<StopWatch, Active> { typedef sc::transition<EvReset, Active> reactions; // The extra 'handler' stuff void setHandler(Handler* handler) { m_handler = handler; }; Handler* getHandler() const { return m_handler; }; Handler* m_handler { nullptr }; // Used to make post_event() accessible from an external class...seems unpleasant, but... using sc::state_machine<StopWatch, Active>::post_event; }; // The implementation of the Handler class; created with a reference to a StopWatch object struct Handler { Handler(StopWatch& stopWatch) : m_stopWatch { stopWatch } {}; void doPost() { m_stopWatch.post_event(EvStartStop()); } void doProcess() { m_stopWatch.process_event(EvStartStop()); } StopWatch& m_stopWatch; }; struct Stopped; struct Active : sc::state<Active, StopWatch, Stopped> { Active(my_context ctx) : my_base { ctx } { std::cout << "Entered Active" << std::endl; }; ~Active() { std::cout << "Exited ~Active" << std::endl; }; typedef mpl::list<sc::custom_reaction<EvPayload1>, sc::custom_reaction<EvPayload2>, sc::transition<EvReset, Active>> reactions; sc::result react(const EvPayload1& payload1) { std::cout << "payload1 Event NOT HANDLED" << std::endl; return discard_event(); } sc::result react(const EvPayload2& payload2) { std::cout << "Active - payload2 m_charValue: " << payload2.m_charValue << std::endl; return discard_event(); } }; struct Running : sc::state<Running, Active> { Running(my_context ctx) : my_base { ctx } { std::cout << "Entered Running" << std::endl; }; ~Running() { std::cout << "Exited ~Running" << std::endl; }; typedef mpl::list<sc::custom_reaction<EvPayload1>, sc::transition<EvStartStop, Stopped>> reactions; sc::result react(const EvPayload1& payload1) { std::cout << "payload1 value1: " << payload1.m_value1 << std::endl; std::cout << "payload1 value2: " << payload1.m_value2 << std::endl; //***context<StopWatch>().getHandler()->doPost(); context<StopWatch>().getHandler()->doProcess(); return discard_event(); } }; struct Stopped : sc::state<Stopped, Active> { Stopped(my_context ctx) : my_base { ctx } { std::cout << "Entered Stopped" << std::endl; }; ~Stopped() { std::cout << "Exited ~Stopped" << std::endl; }; typedef mpl::list<sc::custom_reaction<EvPayload2>, sc::transition<EvStartStop, Running>> reactions; sc::result react(const EvPayload2& payload2) { std::cout << "Stopped - payload2 m_charValue: " << payload2.m_charValue << std::endl; //***context<StopWatch>().getHandler()->doPost(); context<StopWatch>().getHandler()->doProcess(); return forward_event(); } }; int main() { StopWatch myWatch; Handler myHandler(myWatch); myWatch.setHandler(&myHandler); myWatch.initiate(); myWatch.process_event(EvPayload2 { 'a' }); myWatch.process_event(EvPayload1 { 20, 200.2 }); std::cout << "Exiting Program" << std::endl; return 0; }

1 1

Iterate intrusive list without container?
by John W 24 Oct '21

24 Oct '21

With a traditional "hand-rolled" doubly-linked list, if you have a reference to a Node, you can traverse from that node to the end of the list easily. Just check for "pNext == NULL" to know when you're at the end. You don't need any reference to the owning "list container" object. However, I can't seem to accomplish the same with boost::intrusive::list. Traversal with an intrusive::list's iterator is done STL-style, and for that you need to compare to the container's ".end()" value. I am aware of the "s_iterator_to" function[1], which can statically get an iterator from a node, but there doesn't seem to be any way to statically get a usable ".end()" value to compare to. There is also "container_from_end_iterator"[2], which gives the container if you have "end()" available already — not quite what I want, but I guess shows that end() is intimately tied to the container. I also notice that if I have an iterator to the last element in a list, and I increment it (++iterator), no error is given. But if I try to dereference it, I get garbage data. Peeking into the implementation, from what I can tell, boost::intrusive::list is actually a circular list, with a special "root node" that the container owns, and which represents the "end". So, iterating beyond the end gives you that root node. I guess my questions are: (1) Is my analysis above correct? I feel I might have missed something wading through all the templates, and the docs I've found don't discuss these implementation details. (2) Is there any way to accomplish what I want? That is: iterating from an arbitrary node to the end of the list, *without* a reference to the owning container? (3) [aside] If the answer to the above is "no", does anyone know what the rationale is for this design choice? It seems odd that such a basic feature of a traditional hand-made intrusive list would be dropped if there were no benefit. Thanks -John [1] https://github.com/boostorg/intrusive/blob/f44b0102b4ee9acf7b0304b3f5b27dde… [2] https://github.com/boostorg/intrusive/blob/f44b0102b4ee9acf7b0304b3f5b27dde…

3 2

Conversion from exception_ptr to shared_ptr
by rajesh daggumati 19 Oct '21

19 Oct '21

HI, please help me to solve below issue. Shared pointers are used in my code. class Exception : public virtual std::exception,public virtual boost::exception { --- }; class ExceptionTestException : public Exception { --- }; boost::shared_ptr<Exception> exceptionptr_t; try { Boost_Throw_function(ExceptionTestException("Hiii")); } catch(...) { boost::exception_ptr exceptionptr = boost::current_exception(); try { boost::rethrow(exceptionptr) } catch(boost::exception &e) { //here i need to assign this 'e' to shared pointer but this e is not in heap so then how to assign this e to sharedptr(exceptionptr_t). 1 way is : boost::exception *ep = new ExceptionTestException(e); exceptionptr_t(ep); here we know that exception_ptr is having ExceptionTestException but in some cases, we dont know which type of excepiton we have in exception_ptr in runtime. then how to assign to shared_ptr

1 0

Version 77 download not a bz2 file
by Chris 16 Oct '21

16 Oct '21

Trying to use version 77 I get a "wrong checksum" message: Failed to download sources: module boost: Wrong sha256 checksum for boost_1_77_0.tar.bz2, expected "fc9f85fc030e233142908241af7a846e60630aa7388de9a5fafb1f3a26840854", was "4ffd1325229da00455ae95a68de976d053e46315628ffcd57a433238e74e7eab" If I change the checksum in the download command to that shown above I get a "not a .bz2 file" message. Chris

2 4

Thread crash in destructor
by Alexander Carôt 08 Oct '21

08 Oct '21

Hi all, I had been using an old boost system and boost thread lib for a couple of years without upgrading it since approx. 2014. With this old lib the following (simplified) code works fine on OSX: #include "test.h" test::test() { boost::thread::attributes attrs; /// START TRACEROUTE THREAD #if defined(BOOST_THREAD_PLATFORM_WIN32) res = SetThreadPriority(attrs.native_handle(), THREAD_PRIORITY_NORMAL); #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) pthread_attr_setschedpolicy(attrs.native_handle(), SCHED_FIFO); #endif tracerouteThread = boost::thread( attrs, boost::bind(&test::performTraceroute, this)); } void test::performTraceroute() { cout << "START TRACEROUTE" << endl; string exec = ""; cout << "DO FURTHER STUFF BUT THIS IS JUST A DEMO ..." << endl; cout << "THREAD OVER" << endl; } Using the current boost 1_77 still does execute the thread but then it crashes within the destructor. Adding tracerouteThread.join() or .detach() after launching the thread does not help either. Can anyone help how to resolve this issue ? Thanks a lot in advance, best Alex -- http://www.carot.de Email : Alexander(a)Carot.de Tel.: +49 (0)177 5719797

4 5

Re: [Boost-users] Thread crash in destructor
by Alexander Carôt 08 Oct '21

08 Oct '21

see below – scanning my own info I realized: >>Thread 4 Crashed: >>0 libboost_thread.dylib 0x000000010e4a4570 tls_destructor + 96 ... that it linked to a dynamic lib which I did not intend to – I am using a static lib and this made me conclude that I had a path issue so it eventually linked to a wrong lib which eventually caused the issue. After fixing my paths the issue is resolved and it works perfectly fine even with the latest 1_77 Sorry for the confusion and thanks for your help ! Now it would be nice to focus on the thread priority which might possibly be wrong as well. Best Alex Hej Juan, thanks for the quick response ! >>Are you sure detach() and join() do not help? Yes, I checked it several times. I put either tracerouteThread.join() or tracerouteThread.dispatch() right after launching it but it resultet in the same effect. Please find the OSX-report here – thread 4 is the one that crashes (just in case: My app uses Qt): Thread 0:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff69658dfa mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fff69659170 mach_msg + 60 2 com.apple.CoreServices.CarbonCore 0x00007fff30844d1d _scsclient_CacheableGetDataWithStringKey + 207 3 com.apple.CoreServices.CarbonCore 0x00007fff30844c44 RemoteCacheable::GetWithStringKey(unsigned int, char const*, unsigned long*, unsigned int*) + 70 4 com.apple.CoreServices.CarbonCore 0x00007fff30844ae6 _CSGetNamedData + 98 5 com.apple.AppKit 0x00007fff2c6b5e19 _NSPersistentUIGetShmem + 115 6 com.apple.AppKit 0x00007fff2c6b59c0 _NSPersistentUIEstablishTalagentCommunication + 113 7 com.apple.AppKit 0x00007fff2c6b4d91 -[NSApplication finishLaunching] + 66 8 com.apple.AppKit 0x00007fff2c6b4a20 -[NSApplication run] + 244 9 libqcocoa.dylib 0x000000010fcf2f18 QCocoaEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 2120 (qcocoaeventdispatcher.mm:431) 10 org.qt-project.QtCore 0x000000010f637d36 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 470 (qeventloop.cpp:232) 11 org.qt-project.QtCore 0x000000010f62f092 QCoreApplication::exec() + 130 12 com.yourcompany.soundjack 0x000000010dfb6b41 main + 2817 13 libdyld.dylib 0x00007fff69517cc9 start + 1 Thread 1: 0 libsystem_pthread.dylib 0x00007fff69717b68 start_wqthread + 0 Thread 2: 0 libsystem_pthread.dylib 0x00007fff69717b68 start_wqthread + 0 Thread 3: 0 libsystem_pthread.dylib 0x00007fff69717b68 start_wqthread + 0 Thread 4 Crashed: 0 libboost_thread.dylib 0x000000010e4a4570 tls_destructor + 96 1 libboost_thread.dylib 0x000000010e4a5784 thread_proxy + 148 2 libsystem_pthread.dylib 0x00007fff6971c109 _pthread_start + 148 3 libsystem_pthread.dylib 0x00007fff69717b8b thread_start + 15 Thread 4 crashed with X86 Thread State (64-bit): rax: 0x00000010018da37d rbx: 0x00000010018da37d rcx: 0x0000000000000008 rdx: 0x00007fef2dd18320 rdi: 0x00007fef2dd18180 rsi: 0x00000000000120a8 rbp: 0x000070000346ff70 rsp: 0x000070000346ff30 r8: 0x00000000000130a8 r9: 0x0000000000000000 r10: 0x00007fff8fc0dbf8 r11: 0x00007fff8fc0dbf0 r12: 0x00007fef2dd18180 r13: 0x0000000000000000 r14: 0x00007fef2dd18328 r15: 0x0000000000000000 rip: 0x000000010e4a4570 rfl: 0x0000000000010206 cr2: 0x00000010018da385 -- http://www.carot.de Email : Alexander(a)Carot.de Tel.: +49 (0)177 5719797 > Gesendet: Donnerstag, 07. Oktober 2021 um 21:06 Uhr > Von: "Juan Ramírez" <jramirez.uy(a)gmail.com> > An: boost-users(a)lists.boost.org > Cc: "Alexander Carôt" <alexander_carot(a)gmx.net> > Betreff: Re: [Boost-users] Thread crash in destructor > > The behavior changed in BOOST_THREAD_VERSION 3 (which is default in > boost 1.77). Are you sure detach() and join() do not help? > > Can you provide a call stack? > > On 10/7/21 06:09, Alexander Carôt via Boost-users wrote: > > Hi all, > > > > I had been using an old boost system and boost thread lib for a couple of years without upgrading it since approx. 2014. With this old lib the following (simplified) code works fine on OSX: > > > > #include "test.h" > > > > test::test() { > > boost::thread::attributes attrs; > > > > /// START TRACEROUTE THREAD > > #if defined(BOOST_THREAD_PLATFORM_WIN32) > > res = > > SetThreadPriority(attrs.native_handle(), THREAD_PRIORITY_NORMAL); > > #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) > > pthread_attr_setschedpolicy(attrs.native_handle(), SCHED_FIFO); > > #endif > > tracerouteThread = boost::thread( > > attrs, boost::bind(&test::performTraceroute, this)); > > } > > > > void test::performTraceroute() { > > cout << "START TRACEROUTE" << endl; > > > > string exec = ""; > > cout << "DO FURTHER STUFF BUT THIS IS JUST A DEMO ..." << endl; > > cout << "THREAD OVER" << endl; > > } > > > > Using the current boost 1_77 still does execute the thread but then it crashes within the destructor. Adding > > > > tracerouteThread.join() or .detach() after launching the thread does not help either. > > > > Can anyone help how to resolve this issue ? > > > > Thanks a lot in advance, > > best > > > > Alex > > > > -- > > http://www.carot.de > > Email : Alexander(a)Carot.de > > Tel.: +49 (0)177 5719797 > > > > _______________________________________________ > > Boost-users mailing list > > Boost-users(a)lists.boost.org > > https://lists.boost.org/mailman/listinfo.cgi/boost-users > > >

1 0

Build issue on OSX boost 1.77 json lib is not build.
by Jiri Hoogland 07 Oct '21

07 Oct '21

Hi, I have a mysterious issue where on OSX I try to build boost 1.77 with among others the json component but it is not built. On linux there is no issue. The same script builds everything fine. Has anybody come across this by any chance ? I could not find anything from a search on the net. Thanks, Jiri Below are more details. Using the commands listed below in the OSX case, the json lib is not built, and on Linux it is. Switching on more verbosity and using the -a -q -d 5 shows that json is in the output, but not clear why it is not built. This also seems to be the case for 1.76, we tried this on multiple machines. export ZLIB_DIR=/tmp/zlib-1.2.11 export BZIP2_DIR=/tmp/bzip2-1.0.6 ./b2 link=static variant=release cxxflags="-fPIC" cflags="-fPIC" --build-type=minimal -j8 --build-dir=/tmp/boost/build stage --stagedir=/tmp/boost/stage -sBZIP2_SOURCE=${BZIP2_DIR} -sZLIB_SOURCE= ${ZLIB_DIR} -sNO_ZSTD=1 --with-filesystem --with-iostreams --with-regex --with-system --with-json ls -l /tmp/boost/stage/lib # osx 10.15.7 clang 12 cmake 3.21.3 $ uname -a Darwin vola-imac-jiri.local 19.6.0 Darwin Kernel Version 19.6.0: Tue Aug 24 20:28:00 PDT 2021; root:xnu-6153.141.40~1/RELEASE_X86_64 x86_64 $ c++ --version Apple clang version 12.0.0 (clang-1200.0.32.29) Target: x86_64-apple-darwin19.6.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin $ cmake --version cmake version 3.21.3 $ ll /tmp/boost/stage/lib total 2168 drwxr-xr-x 12 jiri wheel 384 Oct 4 09:10 cmake/ -rw-r--r-- 1 jiri wheel 42688 Oct 4 09:10 libboost_atomic.a -rw-r--r-- 1 jiri wheel 85696 Oct 4 09:10 libboost_bzip2.a -rw-r--r-- 1 jiri wheel 207752 Oct 4 09:10 libboost_filesystem.a -rw-r--r-- 1 jiri wheel 156984 Oct 4 09:10 libboost_iostreams.a -rw-r--r-- 1 jiri wheel 486752 Oct 4 09:10 libboost_regex.a -rw-r--r-- 1 jiri wheel 880 Oct 4 09:10 libboost_system.a -rw-r--r-- 1 jiri wheel 116864 Oct 4 09:10 libboost_zlib.a $ ssh docs # lin gcc10 $ uname -a Linux 09964f3495a3 5.10.25-linuxkit #1 SMP Tue Mar 23 09:27:39 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux $ c++ --version c++ (GCC) 10.3.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ cmake --version cmake version 3.20.5 $ ls -l /tmp/boost/stage/lib total 2316 drwxr-xr-x 13 vola wheel 4096 Oct 4 12:19 cmake -rw-r--r-- 1 vola wheel 14472 Oct 4 12:19 libboost_atomic.a -rw-r--r-- 1 vola wheel 171174 Oct 4 12:19 libboost_container.a -rw-r--r-- 1 vola wheel 516560 Oct 4 12:19 libboost_filesystem.a -rw-r--r-- 1 vola wheel 226418 Oct 4 12:19 libboost_iostreams.a *-rw-r--r-- 1 vola wheel 478604 Oct 4 12:19 libboost_json.a* -rw-r--r-- 1 vola wheel 797230 Oct 4 12:19 libboost_regex.a -rw-r--r-- 1 vola wheel 1412 Oct 4 12:19 libboost_system.a -rw-r--r-- 1 vola wheel 146394 Oct 4 12:19 libboost_zlib.a

1 0

[Boost.Asio] Segmentation fault when ::getaddrinfo() returns EAI_SYSTEM without system error code set (errno = 0) - is this a bug?
by Nils Frielinghaus 04 Oct '21

04 Oct '21

Hello Boost users, I experienced a segmentation fault inside Boost in the following scenario: o There was an illegal DNS entry o When resolving that illegal DNS entry on a Yocto-based embedded Linux distribution, ::getaddrinfo() returned with the error code EAI_SYSTEM but errno was set to 0 o The function translate_addrinfo_error(int) in boost/asio/detail/impl/socket_ops.ipp translates this into boost::system::error_code(0, boost::asio::error::get_system_category()) o This is then interpreted as a success by the calling function and the other output parameters of ::getaddrinfo() are accessed which resulted in the segmentation fault My question would be whether this should be considered a bug in the Boost ASIO library? One could argue that the system should not return EAI_SYSTEM with errno not being set properly. But one could also argue that returning EAI_SYSTEM indicates that something went wrong and that the output parameters are not to be accessed. Nils ------ Nils Frielinghaus

4 11