Boost C++ Libraries: Ticket #10624: win_object_handle_service race condition on destroy https://svn.boost.org/trac10/ticket/10624 <p> I caught a random crash in our code base that appears to be due to a race condition in win_object_handle_service. Reproduction steps are essentially just: </p> <p> boost::asio::windows::object_handle* handle = new boost::asio::windows::object_handle(service, hEvent);<br /> handle-&gt;async_wait(...);<br /> <a class="missing wiki">SetEvent</a>(hEvent);<br /> delete handle; </p> <p> The race condition occurs in win_object_handle_service::wait_callback. The last few lines of code in this method are: </p> <blockquote> <p> lock.unlock();<br /> impl-&gt;owner_-&gt;io_service_.post_deferred_completions(completed_ops); </p> </blockquote> <p> The problem is that while the delete of the handle waits on the same lock as the wait_callback, the call into impl-&gt;owner_-&gt;io_service_ happens outside the scope of that lock. Hence there is a race condition that can trigger under multi-threaded/heavy load scenarios where the delete may execute before the call to &gt;io_service_.post_deferred_completions happens </p> <blockquote> <p> lock.unlock();<br /> &lt;----- delete executes here<br /> impl-&gt;owner_-&gt;io_service_.post_deferred_completions(completed_ops); </p> </blockquote> <p> This leaves impl-&gt;owner_ pointing at deleted/unintialized memory, and hence the post_deferred_completions call randomly crashes. I can repro this 100% of the time by just adding a Sleep to emulate load: </p> <blockquote> <p> lock.unlock();<br /> Sleep(1000);<br /> impl-&gt;owner_-&gt;io_service_.post_deferred_completions(completed_ops); </p> </blockquote> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/10624 Trac 1.4.3