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

[Dmitry V. Levin]

On Mon, Mar 14, 2011 at 01:23:48PM +0100, Oleg Nesterov wrote:
> On 03/14, Denys Vlasenko wrote:
> >
> > 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.
> 
> No, it is not trapped (although this depends on how you define this).
> It is really stopped.

Well, it's in some peculiar state that it is not running, and nothing but
SIGKILL or PTRACE_CONT/PTRACE_SYSCALL/PTRACE_SINGLESTEP/PTRACE_DETACH can
change it.  If you say it's not trapped, then I don't know what the trapped
state is. :)

> Just in case, and it is 'T (stopped)' not 'traced' if this matters, but
> we are going to change this this detail.
> 
> > 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.
> 
> I agree. Even if I know what the kernel/strace do, the current output
> looks confusing to me. And do not forget the multi-threading case.
> I didn't verify this, but I guess in this case strace -f reports
> SIGSTOP for every thread, this is simply not true. Only one thread
> recieves SIGSTOP and then stops, all other thread simply stop.

This "double SIGSTOP" issue is already fixed in HEAD, so upcoming
strace-4.6 won't annoy you about that.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20110315/3561068a/attachment.bin>