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)
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.
(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?
(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.
merged fix in commit: 4d57b6ce93a9f3ae99625f964b3a486da01fa116
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