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 wrote:

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