[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