running 5.1-RELEASE with no procfs mounted (lockups?)
tlambert2 at mindspring.com
Fri Jul 18 22:09:53 PDT 2003
John Baldwin wrote:
> Since ktrace logs all syscall entries and exits, it should seem that
> a kdump after the process had exited would show which syscall returned
> EAGAIN quite easily.
This works if the process exits after the EAGAIN; that would only
work for the specific error that people are seeing currently. If
the process does what it's supposed to do when it sees EAGAIN, and
repeats the call, you could get in a tight loop.
The ktrace output could be examined after killing the process,
but until the process exits, there's really no output that can
be examined using kdump.
The problem is that ktrace/kdump rendesvous at a file; truss does
not, so it has some capabilities that ktrace does not. In some
circumstances (e.g. a system crash, where kdump doesn't get a
chance to get at the file, because it's "cleaned up" and not
even fully written, when it's not "cleaned up") ktrace loses
This is not to say that it's not a useful tool (I use it myself);
just that truss has some utility in situations where a tighter
coupling between the tracing and the display of the trace
information is useful.
My second example is a much better case; my first one was mostly
designed for a current discussion about EAGAIN, whereas the most
utility for truss over ktrace involves an actual system crash,
and/or an application that doesn't exit [ab]normally, thus giving
you a synchronized trace file to play with.
It's really all about loosely couple synchronization (ktrace) vs.
tightl couple synchronization (truss).
With truss, you can even expect that in many circumstances, you
will at least get boundary information, even in the face of a
system crash -- this is a situation that ktrace would lose for
sure, if the crash couldn't sync.
More information about the freebsd-hackers