-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[Windows] Launching a child by Boost.Process v2 fails due to a pipe name clash with unrelated (plug-in) DLL running its own child process around the same time #1619
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The report is based on Boost 1.87.0 and the bug is present in the latest sources. |
RK-BFX
added a commit
to boris-fx/boost-asio
that referenced
this issue
Apr 10, 2025
Include numerical representation of local static variable's address into the pipe name to discriminate Boost.Asio instances in independent DLLs. Fixes chriskohlhoff/asio#1619 Also make the code slightly more future-proof and add useful comments and external documentation links.
RK-BFX
added a commit
to boris-fx/chriskohlhoff-asio
that referenced
this issue
Apr 11, 2025
Include numerical representation of local static variable's address into the pipe name to discriminate Boost.Asio instances in independent DLLs. Fixes chriskohlhoff#1619, mirrors [44fdc62](boostorg/asio@44fdc62). Also make the code slightly more future-proof and add useful comments and external documentation links.
RK-BFX
added a commit
to boris-fx/boost-asio
that referenced
this issue
Apr 14, 2025
Include numerical representation of local static variable's address into the pipe name to discriminate Boost.Asio instances in independent DLLs. Fixes chriskohlhoff/asio#1619 Also make the code slightly more future-proof and add useful comments and external documentation links.
RK-BFX
added a commit
to boris-fx/mocha-boost
that referenced
this issue
Apr 14, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
General
Imagine an application that is a plug-in host that loads unrelated DLLs (e.g. from different vendors) as its plug-ins. If two or more such plug-ins use Boost.Process under the hood (e.g. built statically, with no
boost_process*.dll
) to launch child processes and e.g. read their output, and if it happens so that they do it around the same time (e.g. upon project opened), then chances are high that some of them will fail with error 231:All pipe instances are busy
because each plug-in will generate (inside ASIO) and attempt using the same pipe name.Reproduce:
Download the following source files to the same empty folder:
exe.cpp
dll.cpp
It also includes
#if
ed-out code for v1 as that suffers from the same issue (#476).rebuild.cmd
For convenience, they are attached as an archive, along with
vcpkg
configuration files I used to fetch Boost libs:Boost.Process-v2_Windows-pipe-name-clash_2025-04-09.zip
.Adjust the
BOOST_ROOT
variable value inrebuild.cmd
to point to the Boost directory that has its libs built statically (to model the real-life situation and avoid dependency onboost_process*.dll
).Run
rebuild.cmd
— it should produce, among others,EXE.exe
,DLL1.dll
andDLL2.dll
.DLL1.dll
andDLL2.dll
are identical and model two distinct plug-ins.Run
EXE.exe
.Expected:
Assuming the current directory is
F:\Experiments\Boost
, we should get some output like this:doubled and intertwined due to concurrent execution of two threads. E.g.:
Actual:
Due to both plug-ins trying to use the same pipe name, one of the child processes will fail to launch, so we get e.g.:
The text was updated successfully, but these errors were encountered: