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

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.

[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.

[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

[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.