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: about cross-instrumentation


Hi -

> u_globalvar2.stp
>    #! /usr/bin/env stap
>    probe process("./globalvartest").statement("*@globalvartest.c:14") {
>             printf("line 14: fd = %d\n", $fd)
>    }
> [...]

OK.

> target system
> insmod uprobes.ko
> mount -t debugfs none /sys/kernel/debug
> staprun -vv -u u_glo.ko

Run this way, the script may monitor all present & future processes of
the system, not just a single run of ./globalvartest.

(By the way, have you tried the network compiler-server configuration,
so that you don't have to copy stuff by hand so much?)


> and get informantion like
> bash-2.05b# staprun -vv -u u_glo.ko
> staprun:main:273 modpath="u_glo.ko", modname="u_glo"
> [...]
> ERROR: __stp_tf_add_map returned error -12 on pid 8910

A few suggestions:

- Run with stap -DDEBUG_TASK_FINDER -DDEBUG_TASK_FINDER_VMA to
  get more data about how the pid/shlib matching logic in the
  systemtap runtime is working.  It is possible that it is
  running a bit amok and needs tuning.

- Invoke the script in a targeted manner (stap or staprun with
  -c CMD or -x PID), so that less-than-system-wide monitoring
  is being requested.


- FChE


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