Regression: asio crash if mixed c++17 and c++20
The attached archive reproduces asio crash when different translation units use different asio feature configurations for the same asio::strand.
boost_asio_strand_mutex_null.tgz
This commit introduced regression:
commit 0f3093afc95c205b85ae4afb6fa7ef5ef7b921e5 (HEAD)
Author: Christopher Kohlhoff <chris@kohlhoff.com>
Date: Sun Mar 1 11:45:46 2026 +1100
Add a slim mutex implementation.
Added a "slim" mutex implementation based on std::atomic's wait and
notify_one functions. When supported by the compiler / OS, this reduces
the size of the state required for strands, sockets, and other
descriptors.
Cause of the bug (asio strand mutex null)
owner.cpp is compiled as C++20. On the tested macOS/libc++ and linux toolchains, asio defines asio_HAS_STD_ATOMIC_WAIT, so strand_executor_service::strand_impl stores a slim_mutex object.
user.cpp is compiled as C++17. asio does not define asio_HAS_STD_ATOMIC_WAIT, so the same strand_impl type is compiled as though it stores a mutex*. Posting to the C++20-created strand from this C++17 translation unit calls pthread_mutex_lock(nullptr). The CMake target links the C++17 object before the C++20 object so the C++17 asio instantiation is selected, matching the crash observed in the original project.
Output for a non-affected asio version (linux):
owner.cpp asio_HAS_STD_ATOMIC_WAIT=0
user.cpp asio_HAS_STD_ATOMIC_WAIT=0
posting to the C++20-created strand from the C++17 translation unit
post returned
Output for this affected asio commit (linux):
owner.cpp asio_HAS_STD_ATOMIC_WAIT=1
user.cpp asio_HAS_STD_ATOMIC_WAIT=0
posting to the C++20-created strand from the C++17 translation unit
Segmentation fault
Regression: asio crash if mixed c++17 and c++20
The attached archive reproduces asio crash when different translation units use different asio feature configurations for the same
asio::strand.boost_asio_strand_mutex_null.tgz
This commit introduced regression:
Cause of the bug (asio strand mutex null)
owner.cppis compiled as C++20. On the tested macOS/libc++ and linux toolchains, asio definesasio_HAS_STD_ATOMIC_WAIT, sostrand_executor_service::strand_implstores aslim_mutexobject.user.cppis compiled as C++17. asio does not defineasio_HAS_STD_ATOMIC_WAIT, so the samestrand_impltype is compiled as though it stores amutex*. Posting to the C++20-created strand from this C++17 translation unit callspthread_mutex_lock(nullptr). The CMake target links the C++17 object before the C++20 object so the C++17 asio instantiation is selected, matching the crash observed in the original project.Output for a non-affected asio version (linux):
Output for this affected asio commit (linux):