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