Re: ptrace bugs and related problems

["Albert Cahalan" <acahalan@gmail.com>]

On 7/27/06, Daniel Jacobowitz <dan@debian.org> wrote:
> On Thu, Jul 27, 2006 at 09:17:48PM -0400, Albert Cahalan wrote:
> > Minor correction: the message is sent with bad data.
> > Here at home I happen to have 2.6.17-rc5, so
> > looking in the kernel/fork.c file there:
> >
> > The fork_traceflag function looks only at the flags
> > used to follow processes, including PT_TRACE_VFORK.
> >
> > In do_fork, the result of fork_traceflag is assigned
> > to the "trace" variable. Note that PT_TRACE_VFORK_DONE
> > does not cause "trace" to be non-zero.
> >
> > Then we hit this code:
> >
> >                if (unlikely (trace)) {
> >                        current->ptrace_message = nr;
> >                        ptrace_notify ((trace << 8) | SIGTRAP);
> >                }
> >
> > That doesn't run. The ptrace_message is thus not set when
> > ptrace_notify is called to send the PTRACE_EVENT_VFORK_DONE
> > message. You get random stale data from a previous message.
>
> Why do you want the message data anyway?

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.

> > The forced exits show up, oddly. I see one for each task,
> > except for the task which called execve(). The task calling
> > execve() will silently go away. The leader task, despite
> > being reported as dead, returns from execve. Ouch. It would
> > be much more friendly to have the task calling execve()
> > send a (new) PTRACE_EVENT_TID_CHANGE message with the new ID
> > as the ptrace_message. If this is the very last message sent
> > by the task doing execve and is made to arrive in proper order,
> > the debugger can renumber the structures it uses to track tasks.
>
> 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?

> > Note that the new unshare() system call will need to send
> > ptrace events for all tasks affected. Sending the event from
> > one task is no good because the event might arrive after the
> > debugger has responded to some other task. Consider breakpoints
> > in a shared mm, with the mm suddenly becoming unshared.
>
> 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.

> > There is also no way to find all the tasks which share an mm.
> > This is needed so that tasks don't die if the debugger attaches
> > to a pre-existing task and sets a breakpoint.
>
> Ditto.  In practice, thread groups or LinuxThreads libthread_db suffice
> for daily use.
>
> > The /proc/*/auxv files don't work immediately after starting
> > a process via the usual fork,PTRACE_TRACEME,exec method.
> > One has to wait some undetermined amount of time.
>
> I have no idea what this refers to, sorry.

Never mind. I need to use vfork to ensure that the debugger
does not run until the child has done execve. Hopefully the
vfork wake-up won't happen before /proc/*/auxv is ready.
(doing a wait is awkward: I want the data before I enter my
main debugger loop, but the main debugger loop is based on
waitpid and will thus hang if the event is eaten early)

> > 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/