[lldb] Protect the debugger's output and error stream

[JDevlieghere]

Summary

This patch introduces a small utility called ThreadSafeStream to protect the debugger's output and error stream. Nothing prevents someone from bypassing this and going straight through the debugger's Get{Output,Error}File. I don't think we want to get rid of that, but at least now we have something that allows us to access these streams in a safe way.

This fixes a real world race between the main thread and the default event handler thread:

Write of size 8 at 0x000106c01bc0 by thread T1 (mutexes: write M4069, write M2753):
  #0 lldb_private::IOHandlerEditline::PrintAsync(lldb_private::Stream*, char const*, unsigned long) IOHandler.cpp:636 (liblldb.15.0.0git.dylib:arm64+0x3ef4a4)
  #1 lldb_private::IOHandlerStack::PrintAsync(lldb_private::Stream*, char const*, unsigned long) IOHandler.cpp:129 (liblldb.15.0.0git.dylib:arm64+0x3ec84c)
  #2 lldb_private::Debugger::PrintAsync(char const*, unsigned long, bool) Debugger.cpp:1074 (liblldb.15.0.0git.dylib:arm64+0x3cb03c)
  #3 lldb_private::StreamAsynchronousIO::~StreamAsynchronousIO() StreamAsynchronousIO.cpp:21 (liblldb.15.0.0git.dylib:arm64+0x44749c)
  #4 std::__1::__shared_ptr_emplace<lldb_private::StreamAsynchronousIO, std::__1::allocator<lldb_private::StreamAsynchronousIO> >::__on_zero_shared() shared_ptr.h:315 (liblldb.15.0.0git.dylib:arm64+0x3d0f80)
  #5 lldb_private::Debugger::HandleThreadEvent(std::__1::shared_ptr<lldb_private::Event> const&) Debugger.cpp:1591 (liblldb.15.0.0git.dylib:arm64+0x3ce2cc)
  #6 lldb_private::Debugger::DefaultEventHandler() Debugger.cpp:1659 (liblldb.15.0.0git.dylib:arm64+0x3ce720)
  #7 std::__1::__function::__func<lldb_private::Debugger::StartEventHandlerThread()::$_2, std::__1::allocator<lldb_private::Debugger::StartEventHandlerThread()::$_2>, void* ()>::operator()() function.h:352 (liblldb.15.0.0git.dylib:arm64+0x3d145c)
  #8 lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) HostNativeThreadBase.cpp:62 (liblldb.15.0.0git.dylib:arm64+0x4c67a4)
  #9 lldb_private::HostThreadMacOSX::ThreadCreateTrampoline(void*) HostThreadMacOSX.mm:18 (liblldb.15.0.0git.dylib:arm64+0x29cebac)

Previous write of size 8 at 0x000106c01bc0 by main thread (mutexes: write M2754):
  #0 lldb_private::CommandInterpreter::PrintCommandOutput(lldb_private::Stream&, llvm::StringRef) CommandInterpreter.cpp:2992 (liblldb.15.0.0git.dylib:arm64+0x502888)
  #1 lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) CommandInterpreter.cpp:3060 (liblldb.15.0.0git.dylib:arm64+0x502fec)
  #2 non-virtual thunk to lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) CommandInterpreter.cpp (liblldb.15.0.0git.dylib:arm64+0x503410)
  #3 lldb_private::IOHandlerEditline::Run() IOHandler.cpp (liblldb.15.0.0git.dylib:arm64+0x3ef2f4)
  #4 lldb_private::Debugger::RunIOHandlerSync(std::__1::shared_ptr<lldb_private::IOHandler> const&) Debugger.cpp:1037 (liblldb.15.0.0git.dylib:arm64+0x3cabc0)
  #5 lldb_private::CommandInterpreter::HandleCommandsFromFile(lldb_private::FileSpec&, lldb_private::CommandInterpreterRunOptions const&, lldb_private::CommandReturnObject&) CommandInterpreter.cpp:2748 (liblldb.15.0.0git.dylib:arm64+0x5000d4)
  #6 CommandObjectCommandsSource::DoExecute(lldb_private::Args&, lldb_private::CommandReturnObject&) CommandObjectCommands.cpp:187 (liblldb.15.0.0git.dylib:arm64+0x284d0b4)
  #7 lldb_private::CommandObjectParsed::Execute(char const*, lldb_private::CommandReturnObject&) CommandObject.cpp:998 (liblldb.15.0.0git.dylib:arm64+0x50bf04)
  #8 lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&) CommandInterpreter.cpp:1981 (liblldb.15.0.0git.dylib:arm64+0x4feaf0)
  #9 lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) CommandInterpreter.cpp:3049 (liblldb.15.0.0git.dylib:arm64+0x502ee0)
  #10 non-virtual thunk to lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) CommandInterpreter.cpp (liblldb.15.0.0git.dylib:arm64+0x503410)
  #11 lldb_private::IOHandlerEditline::Run() IOHandler.cpp (liblldb.15.0.0git.dylib:arm64+0x3ef2f4)
  #12 lldb_private::Debugger::RunIOHandlers() Debugger.cpp:1008 (liblldb.15.0.0git.dylib:arm64+0x3ca8f8)
  #13 lldb_private::CommandInterpreter::RunCommandInterpreter(lldb_private::CommandInterpreterRunOptions&) CommandInterpreter.cpp:3299 (liblldb.15.0.0git.dylib:arm64+0x5048a4)
  #14 lldb::SBDebugger::RunCommandInterpreter(lldb::SBCommandInterpreterRunOptions const&) SBDebugger.cpp:1203 (liblldb.15.0.0git.dylib:arm64+0x523f8)
  #15 Driver::MainLoop() Driver.cpp:575 (lldb:arm64+0x10000606c)
  #16 main Driver.cpp:851 (lldb:arm64+0x100007388)

[JDevlieghere]

Rename utility class to ThreadSafeStream.

[jingham]

LGTM. It might be worthwhile to audit the uses of Debugger::GetErrorFile & GetOutputFile to see which of them really should also be using the lockable stream instead. That would be fine as a separate commit, however.

[JDevlieghere]

In D121500#3376497, @jingham wrote:

LGTM. It might be worthwhile to audit the uses of Debugger::GetErrorFile & GetOutputFile to see which of them really should also be using the lockable stream instead. That would be fine as a separate commit, however.

Yup, that's exactly what I started doing. I'm aware of at least one offender (https://reviews.llvm.org/D121502) because I just added that. But I'll see if there are other places that can be migrated to use the Stream instead of the File.

[labath]

Are you sure we don't want to handle this at a higher level? The way I understand it, the main reason for the existence of PrintAsync and StreamAsynchronousIO machinery is to provide precise control about when the various bits of output get printed. That's why the asynchronous output gets plumbed through the topmost iohandler and everything. In that setup, I think the right solution would be to set up some synchronization inside/near the iohandler object. If we don't want to bother with that then, we might as well ditch the StreamAsynchronousIO completely.

In D121500#3376501, @JDevlieghere wrote:

Yup, that's exactly what I started doing. I'm aware of at least one offender (https://reviews.llvm.org/D121502) because I just added that. But I'll see if there are other places that can be migrated to use the Stream instead of the File.

Yeah, and I actually came very close to bringing that up (that it should be using StreamAsynchronousIO), but the patch was already submitted, and I did not want to bother with that. But if we're going to start introducing new concepts to make that work, then my calculus changes...

[JDevlieghere]

In D121500#3377321, @labath wrote:

Are you sure we don't want to handle this at a higher level? The way I understand it, the main reason for the existence of PrintAsync and StreamAsynchronousIO machinery is to provide precise control about when the various bits of output get printed. That's why the asynchronous output gets plumbed through the topmost iohandler and everything. In that setup, I think the right solution would be to set up some synchronization inside/near the iohandler object.

Yes, I considered doing the synchronization in the IO handler. We could have the IOHandler class hold onto a mutex. Locking it in PrintAsync takes care of the asynchronous output from the event thread. But everyone else is using the File, StreamFile, FILE* or file descriptor directly, so you need to hand out the mutex every time, in order to avoid colliding with the asynchronous output. That's certainly doable, but how long before someone forgets to lock the mutex? The benefit of doing it at a lower level is that as long as you're using the Stream, you're (somewhat) safe. Somewhat because you could still run into trouble when doing something that results in multiple calls to Stream::WriteImpl. The disadvantage is that we're still in the same boat for whoever is using the other accessors. I guess it's even slightly worse now, because there's no way to get the mutex.

I'm happy to update the patch if you think this is the way to go. Or maybe you had something else in mind?

If we don't want to bother with that then, we might as well ditch the StreamAsynchronousIO completely.

In D121500#3376501, @JDevlieghere wrote:

Yup, that's exactly what I started doing. I'm aware of at least one offender (https://reviews.llvm.org/D121502) because I just added that. But I'll see if there are other places that can be migrated to use the Stream instead of the File.

Yeah, and I actually came very close to bringing that up (that it should be using StreamAsynchronousIO), but the patch was already submitted, and I did not want to bother with that. But if we're going to start introducing new concepts to make that work, then my calculus changes...

I don't think this patch and using StreamAsynchronousIO for the progress updates is mutually exclusive. It sounds like the right thing to use for the progress events regardless, so I'll update D121502 to use that.

[JDevlieghere]

In D121500#3377434, @JDevlieghere wrote:

In D121500#3377321, @labath wrote:

Are you sure we don't want to handle this at a higher level? The way I understand it, the main reason for the existence of PrintAsync and StreamAsynchronousIO machinery is to provide precise control about when the various bits of output get printed. That's why the asynchronous output gets plumbed through the topmost iohandler and everything. In that setup, I think the right solution would be to set up some synchronization inside/near the iohandler object.

Yes, I considered doing the synchronization in the IO handler. We could have the IOHandler class hold onto a mutex. Locking it in PrintAsync takes care of the asynchronous output from the event thread. But everyone else is using the File, StreamFile, FILE* or file descriptor directly, so you need to hand out the mutex every time, in order to avoid colliding with the asynchronous output. That's certainly doable, but how long before someone forgets to lock the mutex? The benefit of doing it at a lower level is that as long as you're using the Stream, you're (somewhat) safe. Somewhat because you could still run into trouble when doing something that results in multiple calls to Stream::WriteImpl. The disadvantage is that we're still in the same boat for whoever is using the other accessors. I guess it's even slightly worse now, because there's no way to get the mutex.

https://reviews.llvm.org/D121537 shows what that would look like

[labath]

In D121500#3377434, @JDevlieghere wrote:

In D121500#3377321, @labath wrote:

Are you sure we don't want to handle this at a higher level? The way I understand it, the main reason for the existence of PrintAsync and StreamAsynchronousIO machinery is to provide precise control about when the various bits of output get printed. That's why the asynchronous output gets plumbed through the topmost iohandler and everything. In that setup, I think the right solution would be to set up some synchronization inside/near the iohandler object.

Yes, I considered doing the synchronization in the IO handler. We could have the IOHandler class hold onto a mutex. Locking it in PrintAsync takes care of the asynchronous output from the event thread. But everyone else is using the File, StreamFile, FILE* or file descriptor directly, so you need to hand out the mutex every time, in order to avoid colliding with the asynchronous output. That's certainly doable, but how long before someone forgets to lock the mutex? The benefit of doing it at a lower level is that as long as you're using the Stream, you're (somewhat) safe. Somewhat because you could still run into trouble when doing something that results in multiple calls to Stream::WriteImpl. The disadvantage is that we're still in the same boat for whoever is using the other accessors. I guess it's even slightly worse now, because there's no way to get the mutex.

I agree with your analysis. I haven't inspected the callers, but I'd say the right solution is to cut down on the number of places that call these functions. Most of the time, this is not the right function to call. We could try to make that more explicit, by adding some comments, or even reducing the scope/visibility of those functions.

In D121500#3376501, @JDevlieghere wrote:

Yup, that's exactly what I started doing. I'm aware of at least one offender (https://reviews.llvm.org/D121502) because I just added that. But I'll see if there are other places that can be migrated to use the Stream instead of the File.

Yeah, and I actually came very close to bringing that up (that it should be using StreamAsynchronousIO), but the patch was already submitted, and I did not want to bother with that. But if we're going to start introducing new concepts to make that work, then my calculus changes...

I don't think this patch and using StreamAsynchronousIO for the progress updates is mutually exclusive.

Depends how you look at it. Without StreamAsynchronousIO, this becomes the ~only way to ensure thread safety. If we move everything to StreamAsynchronousIO, then this could still be useful as an extra line of defence, but one could also say that the lack of the mutex (and the resulting tsan errors) are an extra line of defence against people misusing the output streams. I would put myself in the second camp.

(btw, you did not update the setters in Debuggers::Set(Output|Error)File)

lldb/include/lldb/Core/IOHandler.h

public:
   bool GetIsRealTerminal();
 
   void SetPopped(bool b);
 
   void WaitForPop();
 
   virtual void PrintAsync(const char *s, size_t len, bool is_stdout);
 
+  std::mutex &GetOutputMutex() { return m_output_mutex; }
+
 protected:
   Debugger &m_debugger;
   lldb::FileSP m_input_sp;
   lldb::StreamFileSP m_output_sp;
   lldb::StreamFileSP m_error_sp;
+  std::mutex m_output_mutex;
   repro::DataRecorder *m_data_recorder;
   Predicate<bool> m_popped;
   Flags m_flags;
   Type m_type;
   void *m_user_data;
   bool m_done;
   bool m_active;
 

lldb/include/lldb/Host/Editline.h

 using namespace line_editor;
 
 /// Instances of Editline provide an abstraction over libedit's EditLine
 /// facility.  Both
 /// single- and multi-line editing are supported.
 class Editline {
 public:
   Editline(const char *editor_name, FILE *input_file, FILE *output_file,
-           FILE *error_file, bool color_prompts);
+           FILE *error_file, std::mutex &output_mutex, bool color_prompts);
 
   ~Editline();
 
   /// Uses the user data storage of EditLine to retrieve an associated instance
   /// of Editline.
   static Editline *InstanceFor(::EditLine *editline);
 
   /// Sets a string to be used as a prompt, or combined with a line number to
#endif
 
   CompleteCallbackType m_completion_callback;
   SuggestionCallbackType m_suggestion_callback;
 
   std::string m_suggestion_ansi_prefix;
   std::string m_suggestion_ansi_suffix;
 
   std::size_t m_previous_autosuggestion_size = 0;
-  std::mutex m_output_mutex;
+  std::mutex &m_output_mutex;
 };
 }
 
 #endif // #if defined(__cplusplus)
 #endif // LLDB_HOST_EDITLINE_H

lldb/include/lldb/Interpreter/CommandInterpreter.h

private:
   CommandObject *ResolveCommandImpl(std::string &command_line,
                                     CommandReturnObject &result);
 
   void FindCommandsForApropos(llvm::StringRef word, StringList &commands_found,
                               StringList &commands_help,
                               const CommandObject::CommandMap &command_map);
 
   // An interruptible wrapper around the stream output
-  void PrintCommandOutput(Stream &stream, llvm::StringRef str);
+  void PrintCommandOutput(IOHandler &io_handler, llvm::StringRef str,
+                          bool is_stdout);
 
   bool EchoCommandNonInteractive(llvm::StringRef line,
                                  const Flags &io_handler_flags) const;
 
   // A very simple state machine which models the command handling transitions
   enum class CommandHandlingState {
     eIdle,
     eInProgress,

lldb/source/Core/IOHandler.cpp

bool IOHandler::GetIsRealTerminal() {
   return GetInputFileSP() ? GetInputFileSP()->GetIsRealTerminal() : false;
 }
 
 void IOHandler::SetPopped(bool b) { m_popped.SetValue(b, eBroadcastOnChange); }
 
 void IOHandler::WaitForPop() { m_popped.WaitForValueEqualTo(true); }
 
 void IOHandler::PrintAsync(const char *s, size_t len, bool is_stdout) {
+  std::lock_guard<std::mutex> guard(m_output_mutex);
   lldb::StreamFileSP stream = is_stdout ? m_output_sp : m_error_sp;
   stream->Write(s, len);
   stream->Flush();
 }
 
 bool IOHandlerStack::PrintAsync(const char *s, size_t len, bool is_stdout) {
   std::lock_guard<std::recursive_mutex> guard(m_mutex);
   if (!m_top)

 
 #if LLDB_ENABLE_LIBEDIT
   bool use_editline = false;
 
   use_editline = GetInputFILE() && GetOutputFILE() && GetErrorFILE() &&
                  m_input_sp && m_input_sp->GetIsRealTerminal();
 
   if (use_editline) {
-    m_editline_up = std::make_unique<Editline>(editline_name, GetInputFILE(),
-                                               GetOutputFILE(), GetErrorFILE(),
-                                               m_color_prompts);
+    m_editline_up = std::make_unique<Editline>(
+        editline_name, GetInputFILE(), GetOutputFILE(), GetErrorFILE(),
+        GetOutputMutex(), m_color_prompts);
     m_editline_up->SetIsInputCompleteCallback(
         [this](Editline *editline, StringList &lines) {
           return this->IsInputCompleteCallback(editline, lines);
         });
 
     m_editline_up->SetAutoCompleteCallback([this](CompletionRequest &request) {
       this->AutoCompleteCallback(request);
     });
#if LLDB_ENABLE_LIBEDIT
   if (m_editline_up)
     m_editline_up->Interrupt();
 #endif
 }
 
 void IOHandlerEditline::PrintAsync(const char *s, size_t len, bool is_stdout) {
 #if LLDB_ENABLE_LIBEDIT
   if (m_editline_up) {
+    std::lock_guard<std::mutex> guard(m_output_mutex);
     lldb::StreamFileSP stream = is_stdout ? m_output_sp : m_error_sp;
     m_editline_up->PrintAsync(stream.get(), s, len);
   } else
 #endif
   {
 #ifdef _WIN32
     const char *prompt = GetPrompt();
     if (prompt) {

lldb/source/Host/common/Editline.cpp

 
 Editline *Editline::InstanceFor(EditLine *editline) {
   Editline *editor;
   el_get(editline, EL_CLIENTDATA, &editor);
   return editor;
 }
 
 Editline::Editline(const char *editline_name, FILE *input_file,
-                   FILE *output_file, FILE *error_file, bool color_prompts)
+                   FILE *output_file, FILE *error_file,
+                   std::mutex &output_mutex, bool color_prompts)
     : m_editor_status(EditorStatus::Complete), m_color_prompts(color_prompts),
       m_input_file(input_file), m_output_file(output_file),
-      m_error_file(error_file), m_input_connection(fileno(input_file), false) {
+      m_error_file(error_file), m_input_connection(fileno(input_file), false),
+      m_output_mutex(output_mutex) {
   // Get a shared history instance
   m_editor_name = (editline_name == nullptr) ? "lldb-tmp" : editline_name;
   m_history_sp = EditlineHistory::GetHistory(m_editor_name);
 
 #ifdef USE_SETUPTERM_WORKAROUND
   if (m_output_file) {
     const int term_fd = fileno(m_output_file);
     if (term_fd != -1) {

lldb/source/Interpreter/CommandInterpreter.cpp

 
 bool CommandInterpreter::WasInterrupted() const {
   bool was_interrupted =
       (m_command_state == CommandHandlingState::eInterrupted);
   lldbassert(!was_interrupted || m_iohandler_nesting_level > 0);
   return was_interrupted;
 }
 
-void CommandInterpreter::PrintCommandOutput(Stream &stream,
-                                            llvm::StringRef str) {
+void CommandInterpreter::PrintCommandOutput(IOHandler &io_handler,
+                                            llvm::StringRef str,
+                                            bool is_stdout) {
+
+  lldb::StreamFileSP stream = is_stdout ? io_handler.GetOutputStreamFileSP()
+                                        : io_handler.GetErrorStreamFileSP();
   // Split the output into lines and poll for interrupt requests
   const char *data = str.data();
   size_t size = str.size();
   while (size > 0 && !WasInterrupted()) {
     size_t chunk_size = 0;
     for (; chunk_size < size; ++chunk_size) {
       lldbassert(data[chunk_size] != '\0');
       if (data[chunk_size] == '\n') {
         ++chunk_size;
         break;
       }
     }
-    chunk_size = stream.Write(data, chunk_size);
+    {
+      std::lock_guard<std::mutex> guard(io_handler.GetOutputMutex());
+      chunk_size = stream->Write(data, chunk_size);
+    }
     lldbassert(size >= chunk_size);
     data += chunk_size;
     size -= chunk_size;
   }
-  if (size > 0) {
-    stream.Printf("\n... Interrupted.\n");
-  }
-  stream.Flush();
+
+  std::lock_guard<std::mutex> guard(io_handler.GetOutputMutex());
+  if (size > 0)
+    stream->Printf("\n... Interrupted.\n");
+  stream->Flush();
 }
 
 bool CommandInterpreter::EchoCommandNonInteractive(
     llvm::StringRef line, const Flags &io_handler_flags) const {
   if (!io_handler_flags.Test(eHandleCommandFlagEchoCommand))
     return false;
 
   llvm::StringRef command = line.trim();
if (!is_interactive) {
     // previous command and cause any errors to occur (like redefining an
     // alias, get an error and stop parsing the commands file).
     if (line.empty())
       return;
 
     // When using a non-interactive file handle (like when sourcing commands
     // from a file) we need to echo the command out so we don't just see the
     // command output and no command...
-    if (EchoCommandNonInteractive(line, io_handler.GetFlags()))
+    if (EchoCommandNonInteractive(line, io_handler.GetFlags())) {
+      std::lock_guard<std::mutex> guard(io_handler.GetOutputMutex());
       io_handler.GetOutputStreamFileSP()->Printf(
           "%s%s\n", io_handler.GetPrompt(), line.c_str());
     }
+  }
 
   StartHandlingCommand();
 
   OverrideExecutionContext(m_debugger.GetSelectedExecutionContext());
   auto finalize = llvm::make_scope_exit([this]() {
     RestoreExecutionContext();
   });
 
   lldb_private::CommandReturnObject result(m_debugger.GetUseColor());
   HandleCommand(line.c_str(), eLazyBoolCalculate, result);
 
   // Now emit the command output text from the command we just executed
   if ((result.Succeeded() &&
        io_handler.GetFlags().Test(eHandleCommandFlagPrintResult)) ||
       io_handler.GetFlags().Test(eHandleCommandFlagPrintErrors)) {
     // Display any STDOUT/STDERR _prior_ to emitting the command result text
     GetProcessOutput();
 
     if (!result.GetImmediateOutputStream()) {
       llvm::StringRef output = result.GetOutputData();
-      PrintCommandOutput(*io_handler.GetOutputStreamFileSP(), output);
+      PrintCommandOutput(io_handler, output, true);
     }
 
     // Now emit the command error text from the command we just executed
     if (!result.GetImmediateErrorStream()) {
       llvm::StringRef error = result.GetErrorData();
-      PrintCommandOutput(*io_handler.GetErrorStreamFileSP(), error);
+      PrintCommandOutput(io_handler, error, false);
     }
   }
 
   FinishHandlingCommand();
 
   switch (result.GetStatus()) {
   case eReturnStatusInvalid:
   case eReturnStatusSuccessFinishNoResult:

lldb/unittests/Editline/EditlineTest.cpp

bool GetLines(lldb_private::StringList &lines, bool &interrupted,
                 size_t timeout_millis);
 
   void ConsumeAllOutput();
 
 private:
   bool IsInputComplete(lldb_private::Editline *editline,
                        lldb_private::StringList &lines);
 
+  std::mutex output_mutex;
   std::unique_ptr<lldb_private::Editline> _editline_sp;
 
   PseudoTerminal _pty;
   int _pty_primary_fd = -1;
   int _pty_secondary_fd = -1;
 
   std::unique_ptr<FilePointer> _el_secondary_file;
 };
EditlineAdapter::EditlineAdapter()
   _el_secondary_file.reset(new FilePointer(fdopen(_pty_secondary_fd, "rw")));
   EXPECT_FALSE(nullptr == *_el_secondary_file);
   if (*_el_secondary_file == nullptr)
     return;
 
   // Create an Editline instance.
   _editline_sp.reset(new lldb_private::Editline(
       "gtest editor", *_el_secondary_file, *_el_secondary_file,
-      *_el_secondary_file, false));
+      *_el_secondary_file, output_mutex, false));
   _editline_sp->SetPrompt("> ");
 
   // Hookup our input complete callback.
   auto input_complete_cb = [this](Editline *editline, StringList &lines) {
     return this->IsInputComplete(editline, lines);
   };
   _editline_sp->SetIsInputCompleteCallback(input_complete_cb);
 }