[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