Bug 1005301

Summary: process probes do not parse
Product: [Fedora] Fedora Reporter: Andi Kleen <andi.kleen>
Component: systemtapAssignee: Frank Ch. Eigler <fche>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: andi.kleen, dsmith, fche, jistone, lberk, mjw, nathans, scox, wcohen
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-06 16:42:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Andi Kleen 2013-09-06 15:45:45 UTC 
Description of problem:

tprobe.c:
#include <sys/sdt.h>

main()
{
        DTRACE_PROBE2(test, main, 1, 2);
}

gcc -g -o tprobe tprobe.c

tprobe.stp:
probe process("tprobe").mark("test") { 
        println($arg1)
        println($arg2) 
}

$ sudo stap tprobe.stp 
semantic error: while resolving probe point: identifier 'process' at tprobe.stp:2:7
        source: probe process("tprobe").mark("test") { 
                      ^

semantic error: no match
Pass 2: analysis failed.  [man error::pass2]





Version-Release number of selected component (if applicable):
systemtap-2.3-1.fc19.x86_64
kernel  3.10.10-200.fc19.x86_64 
How reproducible:

Always

Steps to Reproduce:
1. see above
2.
3.

Actual results:
See above

Expected results:

Parse the file, probe the probe.


Additional info:
Comment 1 Frank Ch. Eigler 2013-09-06 16:01:13 UTC 
Hi, Andi.  This just works for me on f19, with same stap version,
but a somewhat earlier kernel (3.10.5).  Can you try ...

% readelf -n tprobe
% stap --vp 03 -L 'process("tprobe").mark("*")'
Comment 2 Lukas Berk 2013-09-06 16:03:52 UTC 
I think actual error here is that the .mark parameter should be .mark("main").  The 'test' parameter is what's referred to as the provider.

More information can be found at https://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps

an alternative probe point could also be process("tprobe").provider("test").mark("main"){...}
Comment 3 Frank Ch. Eigler 2013-09-06 16:05:01 UTC 
Good eyes, Lukas.
Comment 4 Andi Kleen 2013-09-06 16:42:28 UTC 
Ok I tracked it down. It seems to be related to stap not seeing the binary (plus the typo)

Perhaps the documentation should be clearer on this.

For example if I specify an absolute path, does it always match the same binary even when called non absolute? I presume it does because it's matching on the inode.
Comment 5 Frank Ch. Eigler 2013-09-06 16:48:05 UTC 
The stapprobes man page includes this:

> Note that for all process probes, PATH names refer to executables
> that are searched the same way shells do: relative to the working
> directory if they contain a "/" character, otherwise in $PATH.
> [...]

The runtime will indeed match things absolutely, not just by inode but
via elf build-ids.