public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* odd behavior in stap statement probes with varied wildcards
@ 2015-03-12 12:55 BR Chrisman
  2015-03-16 17:14 ` Jonathan Lebon
  0 siblings, 1 reply; 2+ messages in thread
From: BR Chrisman @ 2015-03-12 12:55 UTC (permalink / raw)
  To: systemtap

Description:
statement("*@<file>:<line>") *doesn't* find the probe point
statement("<function>@<file>:<line>") *does* find the probe point.
statement("*@<file>:*") *does* find the probe point (grepped)
statement("*@<file>:0,<line>") *does* find the probe point
statement("*@<file>:<line>,<line>) *does* find the probe point

Theory: Possible interaction bug with the wildcarding between function
specifier and line number specifier which is somehow overridden with
comma-separated line specifier or line-number wildcarding.

I'm a bit familiar with this code, so I can put some eyeballs on it.

---
This is a transcript that I've modified just to simplify the binary
name to 'Binary', the source file to 'foo.h', and the function name to
'myfunction' from their original (very unreadable) values.
---
[root@buildvm-2adb537a-8af2-4184-9f64-42c3a9329afa ~]# stap -v -e
'global tmp318; probe process("Binary").statement("*@*/foo.h:0,366")
if (tmp318 == 0) { tmp318++; println(pp()); }'
Pass 1: parsed user script and 111 library script(s) using
207960virt/35752res/3164shr/32876data kb, in 170usr/10sys/183real ms.
Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 1
global(s) using 234888virt/63464res/3864shr/59804data kb, in
420usr/30sys/453real ms.
Pass 3: using cached
/root/.systemtap/cache/30/stap_30b7d2b815e7a2fe3fae6880268de171_1826.c
Pass 4: using cached
/root/.systemtap/cache/30/stap_30b7d2b815e7a2fe3fae6880268de171_1826.ko
Pass 5: starting run.
^CPass 5: run completed in 0usr/10sys/2652real ms.
[root@buildvm-2adb537a-8af2-4184-9f64-42c3a9329afa ~]# stap -v -e
'global tmp318; probe process("Binary").statement("*@*/foo.h:366,0")
if (tmp318 == 0) { tmp318++; println(pp()); }'
Pass 1: parsed user script and 111 library script(s) using
207960virt/35752res/3164shr/32876data kb, in 150usr/10sys/169real ms.
Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 1
global(s) using 234884virt/63460res/3864shr/59800data kb, in
400usr/50sys/447real ms.
Pass 3: using cached
/root/.systemtap/cache/30/stap_30b7d2b815e7a2fe3fae6880268de171_1826.c
Pass 4: using cached
/root/.systemtap/cache/30/stap_30b7d2b815e7a2fe3fae6880268de171_1826.ko
Pass 5: starting run.
^CPass 5: run completed in 0usr/10sys/3418real ms.
[root@buildvm-2adb537a-8af2-4184-9f64-42c3a9329afa ~]# stap -v -e
'global tmp318; probe process("Binary").statement("*@*/foo.h:366") if
(tmp318 == 0) { tmp318++; println(pp()); }'
Pass 1: parsed user script and 111 library script(s) using
207972virt/35752res/3164shr/32888data kb, in 160usr/10sys/169real ms.
semantic error: no line records for foo.h:366 [man error::dwarf]

semantic error: while resolving probe point: identifier 'process' at
<input>:1:22
        source: global tmp318; probe
process("Binary").statement("*@*/foo.h:366") if (tmp318 == 0) {
tmp318++; println(pp()); }
                                     ^

semantic error: no match

Pass 2: analyzed script: 0 probe(s), 0 function(s), 0 embed(s), 1
global(s) using 224812virt/53188res/3816shr/49728data kb, in
120usr/20sys/140real ms.
Pass 2: analysis failed.  [man error::pass2]
[root@buildvm-2adb537a-8af2-4184-9f64-42c3a9329afa ~]# stap -l
'process("Binary").statement("*@*/foo.h:*")' | grep 'foo.h:366'
process("Binary").statement("myfunction@foo.h:366")
[root@buildvm-2adb537a-8af2-4184-9f64-42c3a9329afa ~]# stap -l
'process("Binary").statement("*@*/foo.h:366")'
[root@buildvm-2adb537a-8af2-4184-9f64-42c3a9329afa ~]# echo $?
1
[root@buildvm-2adb537a-8af2-4184-9f64-42c3a9329afa ~]#
[root@buildvm-2adb537a-8af2-4184-9f64-42c3a9329afa ~]# stap -l
'process("Binary").statement("myfunction@foo.h:366")'
process("Binary").statement("myfunction@foo.h:366")
[root@buildvm-2adb537a-8af2-4184-9f64-42c3a9329afa ~]#

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: odd behavior in stap statement probes with varied wildcards
  2015-03-12 12:55 odd behavior in stap statement probes with varied wildcards BR Chrisman
@ 2015-03-16 17:14 ` Jonathan Lebon
  0 siblings, 0 replies; 2+ messages in thread
From: Jonathan Lebon @ 2015-03-16 17:14 UTC (permalink / raw)
  To: BR Chrisman; +Cc: systemtap

> Description:
> statement("*@<file>:<line>") *doesn't* find the probe point
> statement("<function>@<file>:<line>") *does* find the probe point.
> statement("*@<file>:*") *does* find the probe point (grepped)
> statement("*@<file>:0,<line>") *does* find the probe point
> statement("*@<file>:<line>,<line>) *does* find the probe point

Hmm, I can't reproduce this here (it always finds the probe point).
Going from your "foo.h" hint, I also tried it on functions in header
files and it also found it regardless of the syntax.

If possible, can you reduce it to a simpler reproducible testcase?

Cheers,

Jonathan

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-03-16 17:14 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-12 12:55 odd behavior in stap statement probes with varied wildcards BR Chrisman
2015-03-16 17:14 ` Jonathan Lebon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).