This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: your fault handler is faulty
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Martin Hunt <hunt at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Tue, 6 Sep 2005 08:02:23 -0400
- Subject: Re: your fault handler is faulty
- References: <1125990965.24893.5.camel@dragon>
Hi -
On Tue, Sep 06, 2005 at 12:16:05AM -0700, Martin Hunt wrote:
> [...]
> Most everything I have that does user_string() is now faulting.
> >stap -e 'probe kernel.function("sys_open") {warn("in sys_open");log(user_string($filename))}'
> WARNING: in sys_open
> ERROR: probe faulted near embedded-code at /usr/share/systemtap/tapset/logging.stp:16:28
> [...]
FWIW, I see similar faults during a bunch of other tests, like this one:
global b , a
probe kernel.function("sys_read")
{
a[b++] = (execname() . " " . pp())
if (b>100) exit()
}
probe end {
foreach (aa in a) log(a[aa])
}
> Reverting your latest changes fixes this. WARNING lines alternate
> with valid filenames, so I don't think it is a case where faults
> were simply being ignored before.
Given that the new code is only associated with the kprobes
fault_handler hook, there really should no way the new code can
introduce a regression. I suspect that there are real problems that
we haven't seen before for some reason. Perhaps we need a plain C
kprobes equivalents to demonstrate the problem.
- FChE