Re: ptrace bugs and related problems

[Daniel Jacobowitz <dan@debian.org>]

On Fri, Jul 28, 2006 at 06:28:34PM -0400, Albert Cahalan wrote:
> I was using the data to look up which task just got split away
> from the parent. Judging by Chuck Ebbert's email, I'm not the
> only person to expect the data to be valid.

So it seems!  It seems a reasonable addition if anyone wants to submit
it.

> >Or just present things as if the leader task did the execve, which is
> >effectively what happens, and what I thought would happen for ptrace
> >too.
> 
> That makes things even weirder. A successful execve done in one
> thread appears to be done by another (which might not be
> traced if the debugger was a bit odd), while a failing execve
> appears... where?

Not at all, unless you're doing syscall tracing, I don't think.  The
exec notification is after the mm is replaced.

> >The interface was never designed to handle unsharing.  I don't really
> >think it should be extended to; whoever needs this functionality should
> >design something cleaner for utrace.
> 
> I'm not sure utrace will be accepted. (many ptrace alternatives
> have been born and died over the years) Even if utrace does get
> accepted, initially we only get:
> 
> 1. a clean-up that provides hope for the future
> 2. a hopefully-compatible ptrace on top of utrace
> 3. some sort of demo interface
> 
> That alone won't replace ptrace.

That's why I suggested someone design a cleaner debugging interface to
be implemented on top of utrace - which is how it's supposed to be
used.  Like David, I am confident that this is the future direction of
Linux debugging.

> >> PTRACE_GETSIGINFO has 0x0605 as si_code when a process exits.
> >> This is not defined anywhere.
> >
> >It's garbage.  PTRACE_GETSIGINFO is only valid after the process stops
> >with a signal.
> 
> The process does indeed stop with a signal. It gets SIGTRAP
> as part of sending the ptrace event.

Sure, but you must know what I meant.  PTRACE_GETSIGINFO is only valid
when there is a real signal, i.e. generated by something other than
ptrace.  Which is true whenever wait reports a signal without any of
the special event bits set (except for the legacy SIGTRAP on execve).

-- 
Daniel Jacobowitz
CodeSourcery