[Bug runtime/6897] New: stap not resolving process(pid).statements properly.

[Bug runtime/6897] New: stap not resolving process(pid).statements properly.

[srikar at linux dot vnet dot ibm dot com]

When running a SystemTap script with process(PID) syntax where PID is
non-existant,  I expected SystemTap to exit with an error message. However
SystemTap seems happy enuf to start a probing section.

cat sub.stp
#!/usr/bin/env stap
# Usage: stap <this script> pid
# where pid is an instance of /bin/bash

probe begin { printf("Probing...\n") }

probe process($1).statement(0x0805b834).absolute {
    printf("hello world\n")
}
# ps -aef | grep 9999 | grep -v grep
#
# ./sub.stp -v -v 9999
SystemTap translator/driver (version 0.7.1/0.137 git branch master, commit 6d24a6c9)
Copyright (C) 2005-2008 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
Session arch: i686 release: 2.6.23
Created temporary directory "/tmp/stapVayM4Y"
Searched '/usr/local/share/systemtap/tapset/i686/*.stp', found 2
Searched '/usr/local/share/systemtap/tapset/*.stp', found 43
Pass 1: parsed user script and 45 library script(s) in 980usr/20sys/1007real ms.
Pass 2: analyzed script: 2 probe(s), 0 function(s), 0 embed(s), 0 global(s) in
20usr/0sys/15real ms.
probe_1388 locks nothing
Pass 3: translated to C into
"/tmp/stapVayM4Y/stap_c93fcaf2947ac2443aa9b5e2c7690731_300.c" in
130usr/1130sys/1253real ms.
Pass 4, preamble: (re)building SystemTap's version of uprobes.
Running make -C /usr/local/share/systemtap/runtime/uprobes >/dev/null
Uprobes (re)build complete.
Running make -C "/lib/modules/2.6.23/build" M="/tmp/stapVayM4Y" modules >/dev/null
Pass 4: compiled C into "stap_c93fcaf2947ac2443aa9b5e2c7690731_300.ko" in
9690usr/1430sys/10907real ms.
Copying /tmp/stapVayM4Y/stap_c93fcaf2947ac2443aa9b5e2c7690731_300.ko to
/home/srikar/.systemtap/cache/c9/stap_c93fcaf2947ac2443aa9b5e2c7690731_300.ko
Copying /tmp/stapVayM4Y/stap_c93fcaf2947ac2443aa9b5e2c7690731_300.c to
/home/srikar/.systemtap/cache/c9/stap_c93fcaf2947ac2443aa9b5e2c7690731_300.c
Pass 5: starting run.
Running /usr/local/bin/staprun -v -u
/tmp/stapVayM4Y/stap_c93fcaf2947ac2443aa9b5e2c7690731_300.ko
Probing...
Additional information:
# stap -V
SystemTap translator/driver (version 0.7.1/0.137 git branch master, commit 6d24a6c9)
Copyright (C) 2005-2008 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
# uname -a
Linux llm33.in.ibm.com 2.6.23 #3 SMP Tue Sep 9 12:05:52 IST 2008 i686 i686 i386
GNU/Linux
(On a 2.6.23 + utrace kernel)

-- 
           Summary: stap not resolving process(pid).statements properly.
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: srikar at linux dot vnet dot ibm dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=6897

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

[Bug runtime/6897] stap should assert valid PIDs for process(PID) probes

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-09-17 13:48 -------
I changed the summary line to better reflect the concern.
If this was desirable (I'm unsure), it could be done by
running a test after the task_finder_start work that looks
through all utrace (+ uprobe) probe point specs.  Any
pid-filtered ones that have not become activated could
be treated as a cause for a startup error.

OTOH, we silently permit module("foo") probes where the
foo module is not actually loaded at run time.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|stap not resolving          |stap should assert valid
                   |process(pid).statements     |PIDs for process(PID) probes
                   |properly.                   |


http://sourceware.org/bugzilla/show_bug.cgi?id=6897

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

[Bug runtime/6897] stap should assert valid PIDs for process(PID) probes

[dsmith at redhat dot com]

------- Additional Comments From dsmith at redhat dot com  2008-09-17 14:47 -------
(In reply to comment #0)
> When running a SystemTap script with process(PID) syntax where PID is
> non-existant,  I expected SystemTap to exit with an error message. However
> SystemTap seems happy enuf to start a probing section.

In the current implementation, the module will hang around.  The reason why it
doesn't exit is that pid-based probes at startup are treated much the same as
path-based probes.  If a thread doesn't exist at startup whose path matches,
that isn't an error, since a new thread could come into existence whose path
will match.  Note that we don't monitor new thread creation looking for pids -
that only happens at startup.

I can see the benefits of error'ing out here.  But, I do have a question.  Let's
say your script has 2 pid-based probes - one for pid 10000 and one for pid
50000.  At startup, pid 10000 exists, but pid 50000 doesn't.  Should the user
just receive an error message or should systemtap exit?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6897

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

[Bug runtime/6897] stap should assert valid PIDs for process(PID) probes

[srikar at linux dot vnet dot ibm dot com]

------- Additional Comments From srikar at linux dot vnet dot ibm dot com  2008-09-18 06:03 -------
(In reply to comment #2)
> (In reply to comment #0)
> > When running a SystemTap script with process(PID) syntax where PID is
> > non-existant,  I expected SystemTap to exit with an error message. However
> > SystemTap seems happy enuf to start a probing section.
> 
> In the current implementation, the module will hang around.  The reason why it
> doesn't exit is that pid-based probes at startup are treated much the same as
> path-based probes.  If a thread doesn't exist at startup whose path matches,
> that isn't an error, since a new thread could come into existence whose path
> will match.  Note that we don't monitor new thread creation looking for pids -
> that only happens at startup.
> 
> I can see the benefits of error'ing out here.  But, I do have a question.  Let's
> say your script has 2 pid-based probes - one for pid 10000 and one for pid
> 50000.  At startup, pid 10000 exists, but pid 50000 doesn't.  Should the user
> just receive an error message or should systemtap exit?

If a SystemTap script  refers to a PID then it is likely that it refers to a
existing PID because
- There is no straight way to make the scheduler allocate a specific pid to a
new process.
-  When script refers to a process(PID).statement(STMT) or
process(PID).function("FN") where PID is non-existant, and a new process  starts
and has its pid as PID, then  we aren't sure if we there is a statement at STMT
or a function named "FN".
- Was working as I expected in stap version (0.7/0.131 commit 3e961ba6)

I also failed to highlight a more important problem:
Even if PID were to exist (and is the pid of the process i am interested in)  I
fail to see any probehits. However with version 0.7/0.131 commit 3e961ba6 .. I
can trace the probes.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6897

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

Re: [Bug runtime/6897] stap should assert valid PIDs for process(PID) probes

[Torsten Polle]

Hi Abe,

ajakop at redhat dot com writes:
 > https://sourceware.org/bugzilla/show_bug.cgi?id=6897

 > Abe Jakop <ajakop at redhat dot com> changed:

 >            What    |Removed                     |Added
 > ----------------------------------------------------------------------------
 >                  CC|                            |ajakop at redhat dot com
 >            Assignee|systemtap at sourceware dot org    |ajakop at redhat dot com

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

I'm stumbling over this fix, when I use the sysroot option.

E.g. the call
XDG_DATA_DIRS=/dev/null SYSTEMTAP_DEBUGINFO_PATH=/usr/lib/debug /opt/tooling/adit/systemtap/bin/stap -g -a arm -B CROSS_COMPILE=arm-linux- -r /home/polle/work/linux-2.6 --sysroot=/home/polle/work/sw/buildroot-2011.08/output/target -L 'process("/home/polle/bin/my_test").function("*").call, process("/home/polle/bin/my_test").function("*").inline'
suddenly fails, when patch "5c6f9e9 validate PID in process(PID).* probes" is applied.

Kind Regards,
Torsten

[Bug runtime/6897] stap should assert valid PIDs for process(PID) probes

[ajakop at redhat dot com]

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

Abe Jakop <ajakop at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ajakop at redhat dot com
           Assignee|systemtap at sourceware dot org    |ajakop at redhat dot com

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