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