Re: ptrace bugs and related problems

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

On 7/31/06, Daniel Jacobowitz <dan@debian.org> wrote:
> On Fri, Jul 28, 2006 at 06:28:34PM -0400, Albert Cahalan wrote:
> [somebody - lost ref]

> > >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.

Syscall tracing is pretty much a given I think.
There are numerous reasons to use it, not all
of which I remember. I think some of the reasons
are related to single-stepping over sysenter,
syscall, and int 0x80.

The execve event is unreliable anyway.
Thus, it is necessary to use syscall tracing.

So that leaves a debugger with the weirdness
of a system call that enters via one task and
then exits via a different task. That different
task might have been running (a syscall exit
without an entry within that task) or in some
unrelated syscall (whee... the syscall number
suddenly changed) or even racing in execve.

> > >> 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).

That sucks. I like converting si_code to something
readable that I can present to the user. Well, it seems
to work anyway. The main failure is that an access
to unmapped memory does not give 3 distinct codes
for read/write/execute.
-
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/