[SCM] strace branch, master, updated. v4.5.20-103-g7b6847b

Denys Vlasenko dvlasenk at redhat.com
Mon Mar 14 10:55:44 UTC 2011


On Fri, 2011-03-11 at 23:53 +0300, Dmitry V. Levin wrote:
> On Thu, Mar 10, 2011 at 12:26:08PM +0100, Denys Vlasenko wrote:
> > +				in_job_control_stop = 0;
> > +				if (WSTOPSIG(status) == SIGSTOP ||
> > +				    WSTOPSIG(status) == SIGTSTP ||
> > +				    WSTOPSIG(status) == SIGTTIN ||
> > +				    WSTOPSIG(status) == SIGTTOU) {
> > +					/*
> > +					 * PTRACE_GETSIGINFO fails if this is
> > +					 * genuine *stop* notification,
> > +					 * not *signal* notification
> > +					 */
> > +					siginfo_t si;
> > +					if (ptrace(PTRACE_GETSIGINFO, pid,
> > +						    0, &si) != 0)
> > +						in_job_control_stop = 1;
> > +				}
> >  				printleader(tcp);
> > -				tprintf("--- %s (%s) @ %lx (%lx) ---",
> > +				tprintf(in_job_control_stop
> > +					? "--- stopped by %s ---"
> > +					: "--- %s (%s) @ %lx (%lx) ---",
> 
> In addition to what I've already written in this thread, I want to point
> out that, unfortunately, this "stopped by" wording contradicts with
> reality.  The tracee is just trapped, and there are no means to make
> it really stopped without detaching.

There were several active discussion threads on lkml exactly about this,
which resulted (finally) in actual patches to fix
long-standing problem with strace + ^Z not working properly.
I'm CC'ing participants. If you want to read the last of these threads,
google for "[RFC] Proposal for ptrace improvements".

During those discussions, several people, including me,
were again puzzled by "double SIGSTOP" thing in strace.

I think that making strace explicitly tell the user
how exactly the second SIGSTOP is different from first one
is beneficial. Yes, until kernel work is finished, straced
process won't actually stop, but at least strace messages
will be a bit less obscure.


-- 
vda






More information about the Strace-devel mailing list