systemtap to trace source of syscall error?

Richard W.M. Jones rjones@redhat.com
Mon Dec 20 14:50:00 GMT 2010


On Mon, Dec 20, 2010 at 09:09:14AM -0500, Frank Ch. Eigler wrote:
> "Richard W.M. Jones" <rjones@redhat.com> writes:
> 
> > [...]
> > Unfortunately my reproducer is quite hard to trigger[1], and it's
> > probably happening somewhere inside FUSE, so I was hoping for a way to
> > just grab say a stack trace when it happens.  Oh well ...
> 
> The problem is that by the time the error propagates to userspace, the
> kernel stack has been unwound, so there is nothing to trace exactly.
> 
> However, if you suspect the FUSE subsystem, you could probe there
> instead, not at the syscall boundary.  For example,
> 
> % stap -L 'module("fuse").function("*").return'
> [... many functions ...]
> 
> % sudo stap -vt -e '
> probe module("fuse").function("*").return {
>   if (@defined($return) && $return < 0) println(pp()," ",$return)
> }'
> 
> This should give you a list of functions that have a <0 result code.

Great, systemtap gets more awesome each time I look at it ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



More information about the Systemtap mailing list