[Bug runtime/17986] New: unprivileged_myproc.exp and unprivileged_probes.exp regressed on el6 (systemtap-2.5-5.el6 versus release-2.6-274-gbabad5b31b70)

[Bug runtime/17986] New: unprivileged_myproc.exp and unprivileged_probes.exp regressed on el6 (systemtap-2.5-5.el6 versus release-2.6-274-gbabad5b31b70)

[mcermak at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17986

            Bug ID: 17986
           Summary: unprivileged_myproc.exp and unprivileged_probes.exp
                    regressed on el6 (systemtap-2.5-5.el6 versus
                    release-2.6-274-gbabad5b31b70)
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com

Created attachment 8134
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8134&action=edit
release-2.6-274-gbabad5b31b70 logs showing the failures

The unprivileged_myproc.exp and unprivileged_probes.exp testcases regressed on
el6 (systemtap-2.5-5.el6 versus release-2.6-274-gbabad5b31b70).

Attaching x86_64 logs to demonstrate the issue. Reference logs for 2.5-5.el6
can be found at https://url.corp.redhat.com/2305d37.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/17986] unprivileged_myproc.exp and unprivileged_probes.exp regressed on el6 (systemtap-2.5-5.el6 versus release-2.6-274-gbabad5b31b70)

[dsmith at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17986

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsmith at redhat dot com

--- Comment #1 from David Smith <dsmith at redhat dot com> ---
From looking at the log file, I see the following:

====
FAIL: unprivileged probes: --unprivileged
process.library(string).statement(string).nearest
FAIL: unprivileged probes: --unprivileged process.statement(string).nearest
FAIL: unprivileged probes: --privilege=stapusr process(number).function(number)
with alias
FAIL: unprivileged probes: --unprivileged process(number).function(number).call
FAIL: unprivileged probes: --privilege=stapusr
process(number).function(number).exported with alias
FAIL: unprivileged probes: --unprivileged
process(number).function(number).return
FAIL: unprivileged probes: --privilege=stapusr process(number).function(string)
with alias
FAIL: unprivileged probes: --unprivileged process(number).function(string).call
FAIL: unprivileged probes: --privilege=stapusr
process(number).function(string).callee(string) with alias
FAIL: unprivileged probes: --unprivileged
process(number).function(string).callees
FAIL: unprivileged probes: --privilege=stapusr
process(number).function(string).callees(number) with alias
FAIL: unprivileged probes: --unprivileged
process(number).function(string).exported
FAIL: unprivileged probes: --privilege=stapusr
process(number).function(string).inline with alias
FAIL: unprivileged probes: --unprivileged
process(number).function(string).label(string)
FAIL: unprivileged probes: --privilege=stapusr
process(number).function(string).return with alias
FAIL: unprivileged probes: --unprivileged process(number).mark(string)
FAIL: unprivileged probes: --privilege=stapusr process(number).plt with alias
FAIL: unprivileged probes: --unprivileged process(number).plt.return
FAIL: unprivileged probes: --privilege=stapusr process(number).plt(string) with
alias
FAIL: unprivileged probes: --unprivileged process(number).plt(string).return
FAIL: unprivileged probes: --privilege=stapusr
process(number).provider(string).mark(string) with alias
FAIL: unprivileged probes: --unprivileged process(number).statement(number)
FAIL: unprivileged probes: --privilege=stapusr
process(number).statement(number).nearest with alias
FAIL: unprivileged probes: --unprivileged process(number).statement(string)
FAIL: unprivileged probes: --privilege=stapusr
process(number).statement(string).nearest with alias
FAIL: unprivileged probes: --privilege=stapusr
process(string).library(string).statement(string).nearest with alias
FAIL: unprivileged probes: --privilege=stapusr
process(string).statement(string).nearest with alias
FAIL: unprivileged probes: --privilege=stapsys
process.library(string).statement(string).nearest
FAIL: unprivileged probes: --privilege=stapsys
process.statement(string).nearest
FAIL: unprivileged probes: --privilege=stapsys process(number).function(number)
with alias
FAIL: unprivileged probes: --privilege=stapsys
process(number).function(number).call
FAIL: unprivileged probes: --privilege=stapsys
process(number).function(number).exported with alias
FAIL: unprivileged probes: --privilege=stapsys
process(number).function(number).return
FAIL: unprivileged probes: --privilege=stapsys process(number).function(string)
with alias
FAIL: unprivileged probes: --privilege=stapsys
process(number).function(string).call
FAIL: unprivileged probes: --privilege=stapsys
process(number).function(string).callee(string) with alias
FAIL: unprivileged probes: --privilege=stapsys
process(number).function(string).callees
FAIL: unprivileged probes: --privilege=stapsys
process(number).function(string).callees(number) with alias
FAIL: unprivileged probes: --privilege=stapsys
process(number).function(string).exported
FAIL: unprivileged probes: --privilege=stapsys
process(number).function(string).inline with alias
FAIL: unprivileged probes: --privilege=stapsys
process(number).function(string).label(string)
FAIL: unprivileged probes: --privilege=stapsys
process(number).function(string).return with alias
FAIL: unprivileged probes: --privilege=stapsys process(number).mark(string)
FAIL: unprivileged probes: --privilege=stapsys process(number).plt with alias
FAIL: unprivileged probes: --privilege=stapsys process(number).plt.return
FAIL: unprivileged probes: --privilege=stapsys process(number).plt(string) with
alias
FAIL: unprivileged probes: --privilege=stapsys
process(number).plt(string).return
FAIL: unprivileged probes: --privilege=stapsys
process(number).provider(string).mark(string) with alias
FAIL: unprivileged probes: --privilege=stapsys
process(number).statement(number)
FAIL: unprivileged probes: --privilege=stapsys
process(number).statement(number).nearest with alias
FAIL: unprivileged probes: --privilege=stapsys
process(number).statement(string)
FAIL: unprivileged probes: --privilege=stapsys
process(number).statement(string).nearest with alias
FAIL: unprivileged probes: --privilege=stapsys
process(string).library(string).statement(string).nearest with alias
FAIL: unprivileged probes: --privilege=stapsys
process(string).statement(string).nearest with alias
FAIL: unprivileged myproc: --privilege=stapusr
process.library(string).statement(string).nearest
FAIL: unprivileged myproc: --privilege=stapusr
process.statement(string).nearest
FAIL: unprivileged myproc: --unprivileged
process(number).function(string).callee(string)
FAIL: unprivileged myproc: --unprivileged
process(number).statement(string).nearest
FAIL: unprivileged myproc: --privilege=stapusr
process(string).library(string).statement(string).nearest
FAIL: unprivileged myproc: --privilege=stapusr
process(string).statement(string).nearest
FAIL: unprivileged myproc: --privilege=stapsys
process.library(string).statement(string).nearest
FAIL: unprivileged myproc: --privilege=stapsys
process.statement(string).nearest
FAIL: unprivileged myproc: --privilege=stapsys
process(number).function(string).callee(string)
FAIL: unprivileged myproc: --privilege=stapsys
process(number).statement(string).nearest
FAIL: unprivileged myproc: --privilege=stapsys
process(string).library(string).statement(string).nearest
FAIL: unprivileged myproc: --privilege=stapsys
process(string).statement(string).nearest
====

That's 66 failures. Here's how they break down:

1) 22 failures related to '.nearest' probes. Here's an example of one of those:

====
eval exec stap -p2 --unprivileged -e {probe
process.library("libfoo.so").statement("libfoofunc@libfoo.c:*").nearest {
println ("Hello"); exit (); }} -c ./foo
semantic error: while resolving probe point: identifier 'process' at
<input>:1:7
        source: probe
process.library("libfoo.so").statement("libfoofunc@libfoo.c:*").nearest {
println ("Hello"); exit (); }
                      ^

semantic error: .nearest is only valid with absolute or relative line numbers

Pass 2: analysis failed.  [man error::pass2]
====

Jonathan, should a .nearest probe to a wildcarded line number work?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/17986] unprivileged_myproc.exp and unprivileged_probes.exp regressed on el6 (systemtap-2.5-5.el6 versus release-2.6-274-gbabad5b31b70)

[dsmith at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17986

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jlebon at redhat dot com

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/17986] unprivileged_myproc.exp and unprivileged_probes.exp regressed on el6 (systemtap-2.5-5.el6 versus release-2.6-274-gbabad5b31b70)

[jlebon at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17986

--- Comment #2 from Jonathan Lebon <jlebon at redhat dot com> ---
(In reply to David Smith from comment #1)
> 
> Jonathan, should a .nearest probe to a wildcarded line number work?

Hi David,

I think it could go either way, although my preference would be for not
allowing it simply because it doesn't do anything useful. See also bug 17906:

> Thanks for reporting this, looks like I didn't catch it when I made the change. If I remember correctly, the reasoning was that it didn't make sense to have wildcards with .nearest. E.g. .statement("foo@file.c:15").nearest and .statement("foo@file.c+3").nearest have clear meanings (use the nearest probe-able addrs to these linenos).
> 
> On the other hand, with .statement("foo@file.c:*").nearest, since "*" already means "expand to all possible probe-able linenos", adding a .nearest makes no difference since they will all already be valid linenos. In that sense, I guess we could allow the syntax without really changing behaviour. At the time, I leaned on the stricter interpretation of "this is redundant so the user probably meant something else".

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/17986] unprivileged_myproc.exp and unprivileged_probes.exp regressed on el6 (systemtap-2.5-5.el6 versus release-2.6-274-gbabad5b31b70)

[jlebon at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17986

--- Comment #3 from Jonathan Lebon <jlebon at redhat dot com> ---
As per bug 17906, .nearest probes are now accepted for both wildcarded and
enumerated line number types. The remaining failures in unprivileged_probes.exp
seem to all be from the same error relating to process(number) probes, e.g.:

eval exec stap -p2 --privilege=stapsys -e {probe
process(10).statement(0x00000000004007f0) { println ("Hello"); exit (); }} -c
./foo
semantic error: while resolving probe point: identifier 'process' at
<input>:1:7
        source: probe process(10).statement(0x00000000004007f0) { println
("Hello"); exit (); }
                      ^

semantic error: no match

Pass 2: analysis failed.  [man error::pass2]
FAIL: unprivileged probes: --privilege=stapsys
process(number).statement(number)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/17986] unprivileged_myproc.exp and unprivileged_probes.exp regressed on el6 (systemtap-2.5-5.el6 versus release-2.6-274-gbabad5b31b70)

[dsmith at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17986

--- Comment #4 from David Smith <dsmith at redhat dot com> ---
(In reply to Jonathan Lebon from comment #3)
> As per bug 17906, .nearest probes are now accepted for both wildcarded and
> enumerated line number types. The remaining failures in
> unprivileged_probes.exp seem to all be from the same error relating to
> process(number) probes, e.g.:
> 
> eval exec stap -p2 --privilege=stapsys -e {probe
> process(10).statement(0x00000000004007f0) { println ("Hello"); exit (); }}
> -c ./foo
> semantic error: while resolving probe point: identifier 'process' at
> <input>:1:7
>         source: probe process(10).statement(0x00000000004007f0) { println
> ("Hello"); exit (); }
>                       ^
> 
> semantic error: no match
> 
> Pass 2: analysis failed.  [man error::pass2]
> FAIL: unprivileged probes: --privilege=stapsys
> process(number).statement(number)

On the f21 (3.18.9-200.fc21.x86_64) system where I ran the tests, process 10 is
a kernel thread. I'll try to modify the test so that we point to a real process
and see if that fixes things.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/17986] unprivileged_myproc.exp and unprivileged_probes.exp regressed on el6 (systemtap-2.5-5.el6 versus release-2.6-274-gbabad5b31b70)

[dsmith at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17986

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from David Smith <dsmith at redhat dot com> ---
Fixed in commit 261bff4. Giving the 'process(NUMBER)' probe tests a valid pid
fixed all the failures.

-- 
You are receiving this mail because:
You are the assignee for the bug.