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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
