Re: freezes stap

[David Smith <dsmith@redhat.com>]

That's a reasonable thought, but assume the following script:

stap -ve 'probe kernel.function("vfs_read") { printf("VFS_READ\n") }
probe process("/usr/bin/foo").begin { printf("FOO\n") }  probe
module("bar").function("baz") { printf("BAZ\n") }''

In the case of kernel.function probes, a registration error is final.
We won't ever find that kernel function if we don't find it on a stap
module load. (Of course the weird thing here is that module wouldn't
have gotten compiled unless we found vfs_read() in the kernel
debuginfo, but yet for some reason we couldn't actually attach the
probe.)

In the case of a user process, if /usr/bin/foo isn't running right
now, that isn't an error. The stap module will hang around and wait
for /usr/bin/foo to be run and then attach to it.

In the case of a loadable kernel module, if module "bar" isn't loaded
right now, that isn't an error. The stap module will hang around and
wait for module "bar" to be loaded and then the probe will get
attached.

Basically, each probe type has its own rules. Plus the probe types
don't really know about each other. Doing what you suggest might be
doable, but tricky.

On Mon, Jul 23, 2018 at 9:22 AM Lukas Berk <lberk@redhat.com> wrote:
>
> Hi,
>
> A somewhat tangential thought,
>
> David Smith <dsmith@redhat.com> writes:
> >>> 2) WARNING: probe kernel.function("vfs_read@../fs/read_write.c:418")
> >>> (address 0xffffffff95232f70) registration error (rc -84)
> >>>
> >>> That one is fairly fatal. Your probe couldn't be registered, and
> >>> returned -84. Since your probe couldn't be registered, the module
> >>> won't really do anything.
>
> From a usability standpoint, could we possibly keep track of the number
> of targeted probe points vs successfully registered probe points?  In
> the event none exist, perhaps it'd be worthwhile to exit on our own
> volition.  It might spare users the extra time trying to debug the issue
> with a message elaborating on why (ie, no probe points actually
> registered, nothing for us to do).
>
> Cheers,
> Lukas



-- 
David Smith
Associate Manager
Red Hat