Re: Probingof syscall.*.return fails

[fche at redhat dot com (Frank Ch. Eigler)]

"=?UTF-8?Q?Martin_S=C3=BC=C3=9Fkraut?=" <martin.suesskraut@googlemail.com> writes:

> I try to figure out what syscalls fail, while running a certain process.
> [...]
> probe syscall.*.return {
> [...]

> The script hangs at step 5:
> [...]

Does sysrq-t work at this stage?


> I running systemtap 0.7 under Fedora 8 on
> Linux localhost.localdomain 2.6.25.14-69.fc8 #1 SMP Mon Aug 4 14:20:24
> EDT 2008 i686 i686 i386 GNU/Linux
> in a VM (VirtualBox 2.0.0)

We have seen some strange failures only with simulators running
kprobes-rich kernels.  (Sadly, we've also seen failures that occur
only on real hardware.)  There are some more hints on the
HowToReportBugs wiki page.


> I also tested a version with a C-Implementation of is_err (using
> IS_ERR_VALUE). But this crashes the VM (not only the kernel)
> completely at step 5.

If by chance this error occurs at the very first syscall.return event,
calling panic() in this is_err() may be a good tactic to help debug
what's going on.


> Do you have any suggestions how to probe syscall.*.return?

One possibility is to get away from kprobes and use the utrace-based
probes:

   function iserr () { ... }
   probe process.syscall { if (iserr ($return)) ... }

... but this syntax requires newer than released 0.7 code.  Are you
willing to try building your own systemtap binary?


- FChE