This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Semantic error with demo scripts..


On Friday, September 22, 2006 2:30 PM, S. P. Prasanna wrote:
> Hi,
> 
> I am getting semantic errors while running scripts from small_demo
> directory. This happens on default installation on PPC64 RHEL-4 update
> 4. Also I am not able to use lket as well.
> Please let me know if you need more details.

Ok, let's see what's up...

> # ./proc_snoop.stp
> semantic error: probe point mismatch at position 0 (alternatives:
> _process begin end hrtimer(string) ioblock ioscheduler kernel
> module(string) netdev never pagefault process scheduler scsi syscall
> timer) while: resolving probe point signal.send  
> semantic error: probe point mismatch at position 0 (alternatives:
> _process begin end hrtimer(string) ioblock ioscheduler kernel
> module(string) netdev never pagefault process scheduler scsi syscall
> timer) while: resolving probe point signal.handle  
> Pass 2: analysis failed.  Try again with more '-v' (verbose) options.

You are using a test script from CVS with the default systemtap install
(an older version).  The signal tapset is fairly new, so your installed
version probably doesn't have it.

You could copy tapset/signal.stp into your installed runtime directory,
or modify your copy of proc_snoop to use the old ones
(process.signal_send & process.signal_handle).

Or just update your installed systemtap to a CVS build.

> # stap -v -g sched_snoop.stp Pass 1: parsed user script and 25
> library script(s) in 230usr/0sys/235real ms. 
> semantic error: no match for probe point
> while: resolving probe point kernel.inline("pull_task")
> semantic error: no match for probe point
> while: resolving probe point scheduler.migrate
> Pass 2: analyzed script: 5 probe(s), 29 function(s), 1 global(s) in
> 320usr/50sys/365real ms. 
> Pass 2: analysis failed.  Try again with more '-v' (verbose) options.

Is this a UP kernel?  Some of the scheduler probes only apply to SMP
systems, and I've been meaning to clean it up so they don't error on UP
systems.  I just need a round tuit...

> # ./sys.stp
> semantic error: no match for probe point
> while: resolving probe point kernel.function("sys_chown16")
> semantic error: no match for probe point
> while: resolving probe point kernel.function("sys_fchown16")
> semantic error: no match for probe point
> while: resolving probe point kernel.function("sys_getgid16")

You had more success than I did -- when I run this script I get 14 probe
points not found (on 2.6.9-42.ELsmp i686).  I think the syscall tapset
still needs some '?'s sprinkled on probe points that aren't universally
available.

> # stap -v -e 'probe addevent.syscall {}' -bM Pass 1: parsed user
> script and 25 library script(s) in 230usr/0sys/233real ms. 
> semantic error: probe point mismatch at position 0 (alternatives:
> _process begin end hrtimer(string) ioblock ioscheduler kernel
> module(string) netdev never pagefault process scheduler scsi syscall
> timer) while: resolving probe point addevent.syscall  
> Pass 2: analyzed script: 0 probe(s), 0 function(s), 0 global(s) in
> 0usr/0sys/3real ms. 
> Pass 2: analysis failed.  Try again with more '-v' (verbose) options.

Again I think you're the victim of being out-of-date -- LKET might not
be included in your installed version.  Even if it was, addevent.syscall
will probably fail in the same way that sys.stp did for you, since they
both reference 'syscall.*'.


Josh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]