Message-ID: <20060727203128.GA26390@nevyn.them.org>
Date:	Thu, 27 Jul 2006 16:31:28 -0400
From:	Daniel Jacobowitz <dan@...ian.org>
To:	Albert Cahalan <acahalan@...il.com>
Cc:	torvalds@...l.org, alan@...rguk.ukuu.org.uk, ak@...e.de,
	mingo@...e.hu, arjan@...radead.org, akpm@...l.org,
	linux-kernel@...r.kernel.org, roland@...hat.com
Subject: Re: ptrace bugs and related problems

On Thu, Jul 27, 2006 at 02:55:17AM -0400, Albert Cahalan wrote:
> Many of these bugs are generic, some are pure i386, some are for
> i386 binaries on the x86-64 kernel, and some apply to a bit more.
> Some bugs may involve race conditions: I use a 2-core AMD system.
> Kernels vary, but are generally quite recent. (stock 2.6.17.7,
> FC5's latest update, etc.)

Reporting bugs individually, and with a bit more detail, has the
advantage that people can actually keep track of them and
recognize them; I highly recommend it.  And how are we supposed to
answer bugs that apply individually to kernels of unspecified origin?

> There is a ptrace option to follow vfork, and an option to get a
> message when the parent is released by the child. In kernel/fork.c
> there is a bad attempt at optimization which prevents the release
> message (PTRACE_EVENT_VFORK_DONE) from being sent unless the ptrace
> user also chose the option to follow the vfork child.

This doesn't make sense.  Example?

     wait_for_completion(&vfork);
     if (unlikely (current->ptrace & PT_TRACE_VFORK_DONE))
            ptrace_notify ((PTRACE_EVENT_VFORK_DONE << 8) | SIGTRAP);

When the parent's vfork is done, the parent's debugger gets a
notification.

> The debugger has no way to reliably stop a process without causing
> confusion. The SIGSTOP signal is not queued. The app under debug might
> use SIGSTOP and rely on SIGSTOP to work. The debugger can't steal this.
> Any signal that could be queued can also be blocked. The debugger has
> no way to get notice when a signal has merely been queued, can not
> see into the queue, and can not reasonably adjust the signal mask.

See utrace.  This problem is roughly not solvable using ptrace.

> The PTRACE_EVENT_EXEC messages are just plain unreliable. They don't
> always arrive. Things get especially ugly when a non-leader task
> does an execve.

This is what I meant by vague bug reports.  The code for sending this
event is quite simple.  Things do get ugly when non-leader tasks exec;
I don't know whether the forced exits of other threads are clearly
visible from the debugger.

> A debugger needs to read the vdso page. A debugger might want to use
> either /proc/*/mem or PTRACE_PEEK. One of the architectures can't do
> both. If I remember right, x86-64 can't PTRACE_PEEK.

As far as I know I don't have this problem, on x86_64.

> Suppose my debugger has a few threads. PTRACE_ATTACH will not share.
> All ptrace calls fail for all threads other than the one that attached.
> It really sucks to have to funnel everything through one thread.

This is a known limit of ptrace.  It's discussed periodically.

> BTW, not bugs exactly, but... Getting ptrace events via waitpid is
> horrible. Events arrive in some arbitrary order, with no peeking ahead
> either within a single target process or even across multiple target
> processes. Messages from successful clone/fork/exec may arrive before
> or after the child stops, making for some lovely non-deterministic
> behavior. Also, it's no fun to mix waitpid with signals or select.
> Writing a reliable debugger with ptrace on Linux is absurdly painful.

See utrace.

-- 
Daniel Jacobowitz
CodeSourcery
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists