Opened 8 years ago
Last modified 5 years ago
#10213 new Bugs
Reproducible crash with Boost Asio and io_service::post
| Reported by: | Owned by: | chris_kohlhoff | |
|---|---|---|---|
| Milestone: | To Be Determined | Component: | asio |
| Version: | Boost 1.55.0 | Severity: | Problem |
| Keywords: | Cc: |
Description
On OSX, running the following code repeatedly results in an occasional crash with the stack trace following. Unfortunately, I can't find a workaround nor a fix since I don't actually understand why it is crashing...
using namespace boost::asio; io_service service; io_service::work work(service); boost::thread thread{[&](){ service.reset(); service.run(); } }; service.post([&service](){service.stop();}); thread.join();
Error: signal 11: 0 KimiTestApp 0x0000000105534a02 _Z7handleri + 34 1 libsystem_platform.dylib 0x00007fff97a075aa _sigtramp + 26 2 KimiTestApp 0x00000001054f154d _ZN5boost6detail12shared_countD2Ev + 45 3 libsystem_pthread.dylib 0x00007fff9665691e _pthread_cond_signal + 612 4 KimiTestApp 0x0000000105642c43 _ZN5boost4asio6detail11posix_event17signal_and_unlockINS1_11scoped_lockINS1_11posix_mutexEEEEEvRT_ + 115 5 KimiTestApp 0x0000000105642ab4 _ZN5boost4asio6detail15task_io_service31wake_one_idle_thread_and_unlockERNS1_11scoped_lockINS1_11posix_mutexEEE + 100 6 KimiTestApp 0x000000010564293f _ZN5boost4asio6detail15task_io_service26wake_one_thread_and_unlockERNS1_11scoped_lockINS1_11posix_mutexEEE + 47 7 KimiTestApp 0x000000010564247e _ZN5boost4asio6detail15task_io_service25post_immediate_completionEPNS1_25task_io_service_operationEb + 206 8 KimiTestApp 0x000000010564002e _ZN5boost4asio6detail15task_io_service4postIZN42GlobalTestModule_TestNoOpDieImmediate_Test8TestBodyEvE3$_0EEvRT_ + 190 9 KimiTestApp 0x000000010563ff24 _ZN5boost4asio10io_service4postIZN42GlobalTestModule_TestNoOpDieImmediate_Test8TestBodyEvE3$_0EENS0_12async_resultINS0_12handler_typeIT_FvvEE4typeEE4typeEOS7_ + 68 10 KimiTestApp 0x000000010563fded _ZN42GlobalTestModule_TestNoOpDieImmediate_Test8TestBodyEv + 125
Change History (4)
comment:1 by , 8 years ago
| Severity: | Showstopper → Problem |
|---|
comment:2 by , 8 years ago
comment:3 by , 8 years ago
I can confirm that the crash is gone with this change, thanks for posting.
comment:4 by , 5 years ago
found similar issues https://svn.boost.org/trac10/ticket/12690. Patch works for me as well
Note:
See TracTickets
for help on using tickets.

We hit this bug and fixed it with the following patch:
--- a/boost/asio/detail/posix_event.hpp +++ b/boost/asio/detail/posix_event.hpp @@ -58,8 +58,8 @@ public: { BOOST_ASIO_ASSERT(lock.locked()); signalled_ = true; - lock.unlock(); ::pthread_cond_signal(&cond_); // Ignore EINVAL. + lock.unlock(); } // Reset the event.The issue is that in the task_io_service, the thread_info contains an event, and the thread_info lifetime is protected by the mutex associated with the lock passed into
signal_and_unlock, so there is a race where the event is destroyed after thelock.unlock()but before thepthread_cond_signal().The "Ignore EINVAL" comment suggests that someone hit this issue before. Unfortunately, relying on pthread_cond_signal to return an error (and not crash) is not a sufficient solution.