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 utterly. 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. -- Terry _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"