[Lldb-commits] [PATCH] D19122: LLDB: Fixed race condition on timeout when stopping private state thread

Greg Clayton via lldb-commits lldb-commits at lists.llvm.org
Thu Apr 14 16:31:18 PDT 2016


clayborg added a comment.

> I think the real bug is in StopPrivateStateThread, which only sends the stop state if the thread is still joinable; since I removed the Reset, it is of course still joinable after it exits. But even with the Reset (which we agree shouldn't be there), there is still a race between the time the detach signal is sent and when the thread sees it and exits. It seems once a detach or stop is sent, no further detaches/stops can be sent, regardless of what the thread is doing (since it will exit as soon as it sees the first one). So there should be a flag to that effect somewhere checked in ControlPrivateStateThread. Probably all the calls to `IsJoinable()` should be replaced with calls to `PrivateStateThreadIsValid`, which should be updated to check that flag.

> 

> I don't see a nice way to add this flag for each private state thread, though, instead of for the process object as a whole. But maybe that's all that's necessary?


You can just check the value of m_private_state_control_wait:

  void
  Process::ControlPrivateStateThread (uint32_t signal)
  {
      // Signal the private state thread. First we should copy this is case the
      // thread starts exiting since the private state thread will NULL this out
      // when it exits
      HostThread private_state_thread(m_private_state_thread);
      if (private_state_thread.IsJoinable() && m_private_state_control_wait.GetValue() == false)
      {

m_private_state_control_wait is always false if the private state thread is running. It is set to true immediately after sending a control and syncing with the sender and then it is set back to false. It is set to true again when the thread exits.


Repository:
  rL LLVM

http://reviews.llvm.org/D19122





More information about the lldb-commits mailing list