Logging: Make sure logging machinery is in a consistent state after forking

Summary:
We had a bug where if we had forked (in the ProcessLauncherPosixFork)
while another thread was writing a log message, we would deadlock. This
happened because the fork child inherited the locked log rwmutex, which
would never get unlocked. This meant the child got stuck trying to
disable all log channels.

The bug existed for a while but only started being apparent after
D37930, which started using ThreadLauncher (which uses logging) instead
of std::thread (which does not) for launching TaskPool threads.

The fix is to use pthread_atfork to make sure noone is writing a log
message while we are forking.

Reviewers: zturner, eugene, clayborg

Subscribers: lldb-commits

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

llvm-svn: 316173

1 files changed, 1 insertions, 1 deletions

diff --git a/lldb/source/Utility/Logging.cpp b/lldb/source/Utility/Logging.cpp
index 0bd6d6692e3..c9a6ef1bd1e 100644
--- a/lldb/source/Utility/Logging.cpp
+++ b/lldb/source/Utility/Logging.cpp
@@ -51,7 +51,7 @@ static constexpr Log::Category g_categories[] = {
 
 static Log::Channel g_log_channel(g_categories, LIBLLDB_LOG_DEFAULT);
 
-void lldb_private::InitializeLog() {
+void lldb_private::InitializeLldbChannel() {
   Log::Register("lldb", g_log_channel);
 }