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

Attachment: pgpirHEaJnmmv.pgp
Description: PGP signature

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Strace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/strace-devel

Reply via email to