Sorry, that's StopInfoSignal::WillResume. Jim
On Mar 21, 2014, at 10:54 AM, [email protected] wrote: > Somebody is not paying attention to the "process handle" settings. Normally > SIGSTOP is set not to pass: > > (lldb) process handle SIGSTOP > NAME PASS STOP NOTIFY > ========== ===== ===== ====== > SIGSTOP false true true > > This check should be done in Process::WillResume: > > virtual void > WillResume (lldb::StateType resume_state) > { > ThreadSP thread_sp (m_thread_wp.lock()); > if (thread_sp) > { > if > (thread_sp->GetProcess()->GetUnixSignals().GetShouldSuppress(m_value) == > false) > thread_sp->SetResumeSignal(m_value); > } > } > > I wonder why this isn't happening in your case? > > Jim > > > On Mar 21, 2014, at 10:46 AM, Andrew MacPherson <[email protected]> wrote: > >> Currently when attaching to a running process on Linux, a SIGSTOP signal is >> (incorrectly I think) injected into the inferior on resume. This can be >> reproduced by simply launching any process and then in a separate terminal >> doing: >> >> sudo lldb -p <pid> >> c >> process interrupt >> c >> >> On the second continue the SIGSTOP that was used to stop the process is >> injected into the inferior by being passed to PTRACE_CONT, resulting in the >> process going into a stop state outside the control of LLDB. The SIGSTOP >> comes from the SetResumeSignal() call in POSIXThread and StopInfo. >> >> I can't think of any reason why a SIGSTOP should ever be injected into the >> inferior so as a test I simply prevented it from ever happening: >> >> diff --git a/source/Plugins/Process/Linux/ProcessMonitor.cpp >> b/source/Plugins/Process/Linux/ProcessMonitor.cpp >> index 3dec6de..3079379 100644 >> --- a/source/Plugins/Process/Linux/ProcessMonitor.cpp >> +++ b/source/Plugins/Process/Linux/ProcessMonitor.cpp >> @@ -2209,6 +2209,9 @@ ProcessMonitor::Resume(lldb::tid_t tid, uint32_t signo) >> bool result; >> Log *log (ProcessPOSIXLog::GetLogIfAllCategoriesSet (POSIX_LOG_PROCESS)); >> >> + if (signo == SIGSTOP) >> + signo = eResumeSignalNone; >> + >> if (log) >> log->Printf ("ProcessMonitor::%s() resuming thread = %" PRIu64 " >> with signal %s", __FUNCTION__, tid, >> >> m_process->GetUnixSignals().GetSignalAsCString (signo)); >> >> This resolves the issue and doesn't cause any other problems that I can find >> but almost certainly isn't the proper fix. My main concern is that all of >> the resume signal code is shared with other OSes which I'm guessing treat >> this differently. >> >> Any thoughts as to what the proper fix here might be? >> >> Thanks, >> Andrew >> _______________________________________________ >> lldb-dev mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
