This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: systemtap to trace source of syscall error?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]