Hi Richard,
Thanks for your response, I don't use io_context but use the
boost::asio::io_service &io_service for boost::asio::deadline_timer in
a class object created by shared_ptr. I am sure that the io_service
was in scope at the time crashed.
Thank you.
Jupiter
On 10/14/20, Richard Hodges via Boost
There's not a lot of information to go on here. It looks as if you might have a segfault in the scheduler rather than the timer itself. Is the io_context still in scope?
Happy to chat in real time on slack if you have access to it. I generally hang out in the #beast channel as I maintain this library.
https://cppalliance.org/slack/
On Wed, 14 Oct 2020 at 02:30, Jupiter via Boost
wrote: Hi,
My application is running one thread under boost::asio::io_service, it is an embedded system running on an ARM processor with Linux, so no gdb installed. The application is also using a boost::asio::deadline_timer to call a function every second, but I got following segmentation stack trace:
_ZN5boost4asio6detail9scheduler10do_run_oneERNS1_27conditionally_enabled_mutex11scoped_lockERNS1_21scheduler_thread_infoERKNS_6system10error_codeE+0xdd
_ZN5boost4asio6detail9scheduler3runERNS_6system10error_codeE+0x83
I thought I could run c++filt to demangling the library name, not sure why it didn't demangle the name today.
I used the same boost::asio::deadline_timer version 1.69 for another application running on Ubuntu which was working fine, what I could be missing?
Thank you.
Kind regards,
Jupiter
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- "A man can fail many times, but he isn't a failure until he begins to blame somebody else." -- John Burroughs