3 Commits

Author SHA1 Message Date
Pavel Labath
82ba3f4465 Recommit "[lldb/test] Don't use preexec_fn for launching inferiors"
This recommits b15b1421, which reverted in was reverted in f51c47d98 due to
failures on apple systems. The problem was that the patch introduced a race
where the debug server could start the attach process before the first process
(which isn't supposed to be attached to) was set up. This caused us to attach
to the wrong process.

The new version introduces additional synchronization to ensure that does not
happen.

Original commit message was:
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.
2022-07-07 14:38:33 +02:00
Jonas Devlieghere
f51c47d987
Revert "[lldb/test] Don't use preexec_fn for launching inferiors"
This reverts commit b15b1421bc9a11b318b65b489e5fd58dd917db1f because it
breaks GreenDragon [1]. The bot has been red for several days, so
reverting to green while I take a look.

[1] https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/45012/
2022-07-05 10:12:57 -07:00
Pavel Labath
b15b1421bc [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.
2022-07-01 14:36:01 +02:00