Peter Saunderson | 29 Aug 17:09 2014
Picon

semantic error: libdwfl failure (dwarf_highpc): no error thrown

Hi,

I seem to have an ARM ELF file parse problem with systemtap.  I am using

Systemtap translator/driver (version 2.5/0.148, commit 
release-2.4-404-gae91e3d552af + changes)
Copyright (C) 2005-2014 Red Hat, Inc. and others

On a yocto poky build for ARM with a zynq zc702 CPU with version 3.9 
kernel and get an error:

stap -vvv -p4 -k -e 'probe module("myModule").function("myModule_probe") 
{print("I am here\n"); exit();}'

semantic error: libdwfl failure (dwarf_highpc): no error   thrown from: 
/home/pas/Sources/platform/meta-yocto-oina/yocto/build_oxinst/tmp/work/armv7at2hf-vfp-neon-poky-linux-gnueabi/systemtap/2.5+gitAUTOINC+ae91e3d552-r0/git/dwarf_wrappers.cxx:30

semantic error: while resolving probe point: identifier 'module' at 
<input>:1:7
    thrown from: 
/home/pas/Project/yocto/build_yocto/tmp/work/armv7at2hf-vfp-neon-poky-linux-gnueabi/systemtap/2.5+gitAUTOINC+ae91e3d552-r0/git/elaborate.cxx:1074
         source: probe module("myModule").function("myModule_probe") 
{print("I am here\n"); exit();}
                       ^

semantic error: no match (similar functions: myModule_probe, 
myModule_remove, myModule_scale, myModule_isr, match_of_node) thrown 
from: 
/home/pas/Project/yocto/build_yocto/tmp/work/armv7at2hf-vfp-neon-poky-linux-gnueabi/systemtap/2.5+gitAUTOINC+ae91e3d552-r0/git/tapsets.cxx:7634

(Continue reading)

Hemant Kumar | 27 Aug 22:15 2014
Picon

[PATCH v3 0/3] perf/sdt : Support for SDT markers

This patchset helps in listing dtrace style markers(SDT) present in user space
applications through perf.
SDT Notes/markers are placed at important places by the
developers. They have a negligible overhead when not enabled.
We can enable them and probe at these places and find some important information
like the arguments' values, etc.

We have lots of applications which use SDT markers today, like:
Postgresql, MySql, Mozilla, Perl, Python, Java, Ruby, libvirt, QEMU, glib

To add SDT markers into user applications:
We need to have this header sys/sdt.h present.
sys/sdt.h used is version 3.
If not present, install systemtap-sdt-devel package (for fedora-18).

Please refer to the Documentation patch (3rd patch in this series) to see how the
SDT markers are added to a program.

With this patchset,
- Use perf to list the markers in the app:
# perf list sdt ./user_app

./user_app :
%user_app:foo_start
%user_app:fun_start

This link shows an example of marker probing with Systemtap:
https://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps

Also, this link provides important info regarding SDT notes:
(Continue reading)

joaoandreferro | 22 Aug 22:51 2014
Picon

Systemtap FAQ

Hello all,
   
  I've just installed Systemtap, and to start I have a couple of doubts that I
would like to share with you:
   
  1 - Firstly, what I'm trying to achieve is some kind of interrupt handler:
I would like to momentarily interrupt the execution of the OS, and then be
able to run some code of mine (to start, inject a single bit-flip into a
CPU register), and then resume the execution of the OS, with the
possibility of having information on the pre-interruption context. Is this
somehow possible with Systemtap?
   
  2 - I'm using CentOs 6.5 32 bit (kernel version 2.6.32-431.23.3.el6.i686).
Will Systemtap work here? I think this information may be relevant, since
this isn't the last version of the distro, and some other tools I've
already tried to use in the past didn't worked because of my (old) kernel
version.
   
  Thanks and all the best,
  João

mcermak at redhat dot com | 22 Aug 14:54 2014

[Bug runtime/17301] New: optim_arridx.exp affected by testsuite's timeout feature

https://sourceware.org/bugzilla/show_bug.cgi?id=17301

            Bug ID: 17301
           Summary: optim_arridx.exp affected by testsuite's timeout
                    feature
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: minor
          Priority: P3
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com

It turns out that the timeout feature introduced to the testsuite by commit
d13c9b7 breaks optim_arridx.exp. This testcase relies on the elaboration phase
output being compared to given reference in stap_run_exact(). Following two
snippets got added to the module source:

=====
error:unknown (msg:string)
%{ /* unprivileged */
    /* This is an assignment of a local char[] to a global char*.
       It would normally be just as unsafe as returning a pointer to
       a local variable from a function.  However, the translated
       code ensures that upon an error (last_error != NULL), the
       context stack is only ever unwound, and not reused, before
       the probe-level stp-error call.  */
    CONTEXT->last_error = STAP_ARG_msg;
    CONTEXT->last_stmt = NULL;
(Continue reading)

dsmith at redhat dot com | 19 Aug 20:14 2014

[Bug translator/17292] New: multi-line strings broken

https://sourceware.org/bugzilla/show_bug.cgi?id=17292

            Bug ID: 17292
           Summary: multi-line strings broken
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com

Multi-line strings don't seem to work in systemtap. (Are they supposed to?)

With the following script:

====
probe begin 
{
    str = "hello
there"
    printf("%s\n", str)
}
====

You get this:

====
# stap ./str.stp
(Continue reading)

Torsten Polle | 16 Aug 22:43 2014
Picon
Picon

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

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

dsmith at redhat dot com | 15 Aug 19:34 2014

[Bug translator/17275] New: on s390x, buildok/memory-all-probes.stp fails

https://sourceware.org/bugzilla/show_bug.cgi?id=17275

            Bug ID: 17275
           Summary: on s390x, buildok/memory-all-probes.stp fails
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
              Host: s390x

RHEL7 s390x has utrace (tracepoint-based), but no uprobes:

====
# stap -wp4 ../src/testsuite/buildok/memory-all-probes.stp 
user-space process-tracking facilities not available [man
error::process-tracking]
Pass 4: compilation failed.  [man error::pass4]
====

RHEL5 ia64 has utrace (in-kernel), but no uprobes:

====
# stap -wp4 ../src/testsuite/buildok/memory-all-probes.stp
/home/dsmith/.systemtap/cache/02/stap_0239fcbe16622df8c2eeb7deb70d3958_27536.ko
====

(Continue reading)

mcermak at redhat dot com | 15 Aug 13:33 2014

[Bug runtime/17274] New: prologues.exp, the beaker killer

https://sourceware.org/bugzilla/show_bug.cgi?id=17274

            Bug ID: 17274
           Summary: prologues.exp, the beaker killer
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com

Beaker is opensource (https://beaker-project.org/). In the Beaker environment,
systemtap.base/prologues.exp causes the testsuite termination if run on RHEL6
or F20 (on RHEL7 this doesn't happen). However, this only happens when the
testsuite is automatically scheduled by beaker scheduler. Running prologues.exp
by hand (even on a beaker box) doesn't seem to reproduce the issue.

The prologues.exp calls stap_run() which, on line 63, calls "kill -INT
-[exp_pid]" (commit 5a2e1a2b). This (possibly indirectly) causes "*** buffer
overflow detected ***: expect terminated" which in Beaker results in the
testsuite run termination. This happens on *all* architectures and quite
reliably. Following is an example acquired by running ba0e072 stap bits on
RHEL6/x86_64:

-----------------------------8<----------------------------------
Running ./systemtap.base/procfs_write.exp ...
Executing: kill -INT -26759
*** buffer overflow detected ***: expect terminated
(Continue reading)

dsmith at redhat dot com | 14 Aug 21:43 2014

[Bug runtime/17270] New: uprobes_onthefly.exp causing hang on ppc64

https://sourceware.org/bugzilla/show_bug.cgi?id=17270

            Bug ID: 17270
           Summary: uprobes_onthefly.exp causing hang on ppc64
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com

While testing some of the new on-the-fly code, I ran the uprobes_onthefly.exp
testcase on RHEL7 ppc64 (3.10.0-131.el7.ppc64). The system hung.

Here's what was on the console:
====
[  190.522633] stap_3d75d6d062d98c196aae3c9439721299_5807: module verification
failed: signature and/or required key missing - tainting kernel
[  278.406199] stap module notifier triggered in unexpected state 3
[  282.516143] stap module notifier triggered in unexpected state 3
[  291.866004] stap module notifier triggered in unexpected state 3
[  550.950819] hrtimer: interrupt took 1275312 ns
====

--

-- 
You are receiving this mail because:
You are the assignee for the bug.

(Continue reading)

jlebon at redhat dot com | 11 Aug 23:10 2014

[Bug runtime/17256] New: investigate on-the-fly support for other probe types

https://sourceware.org/bugzilla/show_bug.cgi?id=17256

            Bug ID: 17256
           Summary: investigate on-the-fly support for other probe types
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: jlebon at redhat dot com

As a follow-up to bug 10995, investigate other probe types where support for
on-the-fly operations would be worth adding (e.g. probe types with high
overhead cost).

BASIC IMPLEMENTATION INFO

When a probe type supports on-the-fly operations, it means that it is capable
of being turned off (or at least put in a lower-overhead state) during runtime
depending on the value of the probe condition.

For example, imagine we have:

probe foo if (bar) { ... }

If the underlying probe type of 'foo' has otf support, then it will be turned
off (or on) whenever the expression 'bar' transitions from true to false (or
false to true).
(Continue reading)

jlebon at redhat dot com | 11 Aug 21:59 2014

[Bug releng/11179] next release focus

https://sourceware.org/bugzilla/show_bug.cgi?id=11179
Bug 11179 depends on bug 10995, which changed state.

Bug 10995 Summary: on-the-fly enabled/disabled probes
https://sourceware.org/bugzilla/show_bug.cgi?id=10995

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--

-- 
You are receiving this mail because:
You are the assignee for the bug.


Gmane