[all-commits] [llvm/llvm-project] b15b14: [lldb/test] Don't use preexec_fn for launching inf...
Pavel Labath via All-commits
all-commits at lists.llvm.org
Fri Jul 1 05:44:48 PDT 2022
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: b15b1421bc9a11b318b65b489e5fd58dd917db1f
https://github.com/llvm/llvm-project/commit/b15b1421bc9a11b318b65b489e5fd58dd917db1f
Author: Pavel Labath <pavel at labath.sk>
Date: 2022-07-01 (Fri, 01 Jul 2022)
Changed paths:
M lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
M lldb/packages/Python/lldbsuite/test/lldbtest.py
R lldb/test/API/tools/lldb-server/TestGdbRemoteAttachWait.py
A lldb/test/API/tools/lldb-server/attach-wait/Makefile
A lldb/test/API/tools/lldb-server/attach-wait/TestGdbRemoteAttachWait.py
A lldb/test/API/tools/lldb-server/attach-wait/main.cpp
A lldb/test/API/tools/lldb-server/attach-wait/shim.cpp
Log Message:
-----------
[lldb/test] Don't use preexec_fn for launching inferiors
As the documentation states, using this is not safe in multithreaded
programs, and I have traced it to a rare deadlock in some of the tests.
The reason this was introduced was to be able to attach to a program
from the very first instruction, where our usual mechanism of
synchronization -- waiting for a file to appear -- does not work.
However, this is only needed for a single test
(TestGdbRemoteAttachWait) so instead of doing this everywhere, I create
a bespoke solution for that single test. The solution basically
consists of outsourcing the preexec_fn code to a separate (and
single-threaded) shim process, which enables attaching and then executes
the real program.
This pattern could be generalized in case we needed to use it for other
tests, but I suspect that we will not be having many tests like this.
This effectively reverts commit
a997a1d7fbe229433fb458bb0035b32424ecf3bd.
More information about the All-commits
mailing list