Closed ecatmur closed 1 year ago
Assuming beast isn't doing anything screwy here, I think it's valid for shutdown()
to end up calling work_finished()
. The problem is that shutdown()
is called from the destructor ~execution_context()
, when the derived class member io_context::impl_
has already been destroyed.
The simplest fix we've found is to add a call to shutdown()
from ~io_context
:
io_context::~io_context()
{
+ shutdown();
}
io_context::count_type io_context::run()
Hi @ecatmur,
With this change execution_context::service::shutdown
method started being called twice for all services in destroyed instance of io_context
. IMHO, it needs to be described in documentation of execution_context::service::shutdown
method - the fact that this method can be called more than one time before instance of execution_context::service
is destroyed. I got an issue in my custom Asio services after migration to Boost 1.82.0 and fixed it in mabrarov/asio_samples#206.
Thank you.
@mabrarov thanks, added to the documentation.
Fixed by https://github.com/chriskohlhoff/asio/commit/1408e2895c94c8e254e9e8ddd66ba083777f0dc2 (other than documentation).
We found the following msan error from some fairly involved tests:
After a lot of head-scratching we realized that although the msan violation is reported in
asio::detail::scheduler::work_finished()
, it actually arises inasio::io_context::basic_executor_type<std::__1::allocator<void>, 4ul>::~basic_executor_type()
- the bad read is actually the read ofcontext_ptr()->impl_
: