[all-commits] [llvm/llvm-project] caa7e7: [lldb] Make ProcessLauncherPosixFork (mostly) asyn...

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: caa7e765e5ae250c67eab3edd7cd324d3634f779
      https://github.com/llvm/llvm-project/commit/caa7e765e5ae250c67eab3edd7cd324d3634f779
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2021-12-29 (Wed, 29 Dec 2021)

  Changed paths:
    M lldb/include/lldb/Utility/Log.h
    M lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
    M lldb/source/Utility/Log.cpp

  Log Message:
  -----------
  [lldb] Make ProcessLauncherPosixFork (mostly) async-signal-safe

Multithreaded applications using fork(2) need to be extra careful about
what they do in the fork child. Without any special precautions (which
only really work if you can fully control all threads) they can only
safely call async-signal-safe functions. This is because the forked
child will contain snapshot of the parents memory at a random moment in
the execution of all of the non-forking threads (this is where the
similarity with signals comes in).

For example, the other threads could have been holding locks that can
now never be released in the child process and any attempt to obtain
them would block. This is what sometimes happen when using tcmalloc --
our fork child ends up hanging in the memory allocation routine. It is
also what happened with our logging code, which is why we added a
pthread_atfork hackaround.

This patch implements a proper fix to the problem, by which is to make
the child code async-signal-safe. The ProcessLaunchInfo structure is
transformed into a simpler ForkLaunchInfo representation, one which can
be read without allocating memory and invoking complex library
functions.

Strictly speaking this implementation is not async-signal-safe, as it
still invokes library functions outside of the posix-blessed set of
entry points. Strictly adhering to the spec would mean reimplementing a
lot of the functionality in pure C, so instead I rely on the fact that
any reasonable implementation of some functions (e.g.,
basic_string::c_str()) will not start allocating memory or doing other
unsafe things.

The new child code does not call into our logging infrastructure, which
enables us to remove the pthread_atfork call from there.

Differential Revision: https://reviews.llvm.org/D116165


  Commit: daed4797fee4a5f1985388265f5af209b5cb3b10
      https://github.com/llvm/llvm-project/commit/daed4797fee4a5f1985388265f5af209b5cb3b10
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2021-12-29 (Wed, 29 Dec 2021)

  Changed paths:
    M lldb/test/API/functionalities/module_cache/simple_exe/TestModuleCacheSimple.py

  Log Message:
  -----------
  [lldb] Adjust TestModuleCacheSimple for D115951

Now that we are caching the dwarf index as well, we will always have
more than one cache file (when not using accelerator tables). I have
adjusted the test to check for the presence of one _symtab_ index.


Compare: https://github.com/llvm/llvm-project/compare/8de2d06251c3...daed4797fee4