This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Probingof syscall.*.return fails
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: =?UTF-8?Q?Martin_S=C3=BC=C3=9Fkraut? = <martin dot suesskraut at googlemail dot com>
- Cc: systemtap at sourceware dot org
- Date: Tue, 09 Sep 2008 16:29:52 -0400
- Subject: Re: Probingof syscall.*.return fails
- References: <16fcdbda0809090917n62a9addua55d2383e83d2e57@mail.gmail.com>
"=?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