From 1b0539c7f642d266536fb132bc5e7a49ec697cf9 Mon Sep 17 00:00:00 2001 From: Todd Fiala Date: Mon, 27 Jan 2014 17:03:57 +0000 Subject: Fix group stop signal handling issue on Linux. This patch addresses a bug where in a multi-threaded program a new signal from the inferior may be received before all group-stop messages from an earlier signal have been handled. Patch by Andrew MacPherson llvm-svn: 200226 --- lldb/source/Plugins/Process/Linux/ProcessMonitor.cpp | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/lldb/source/Plugins/Process/Linux/ProcessMonitor.cpp b/lldb/source/Plugins/Process/Linux/ProcessMonitor.cpp index 98dd9df5914..51d0d94446b 100644 --- a/lldb/source/Plugins/Process/Linux/ProcessMonitor.cpp +++ b/lldb/source/Plugins/Process/Linux/ProcessMonitor.cpp @@ -1798,14 +1798,23 @@ ProcessMonitor::StopThread(lldb::tid_t tid) int ptrace_err; if (!GetSignalInfo(wait_pid, &info, ptrace_err)) { - if (log) + // another signal causing a StopAllThreads may have been received + // before wait_pid's group-stop was processed, handle it now + if (ptrace_err == EINVAL) { - log->Printf ("ProcessMonitor::%s() GetSignalInfo failed.", __FUNCTION__); + assert(WIFSTOPPED(status) && WSTOPSIG(status) == SIGSTOP); - // This would be a particularly interesting case - if (ptrace_err == EINVAL) - log->Printf ("ProcessMonitor::%s() in group-stop", __FUNCTION__); + if (log) + log->Printf ("ProcessMonitor::%s() resuming from group-stop", __FUNCTION__); + // inferior process is in 'group-stop', so deliver SIGSTOP signal + if (!Resume(wait_pid, SIGSTOP)) { + assert(0 && "SIGSTOP delivery failed while in 'group-stop' state"); + } + continue; } + + if (log) + log->Printf ("ProcessMonitor::%s() GetSignalInfo failed.", __FUNCTION__); return false; } -- cgit v1.2.3