mcermak at redhat dot com | 19 Sep 15:39 2014

[Bug runtime/17414] New: rhel7/ppc64: "stap -p4 -e 'probe nfsd.open{ println(fh) }'" semantic error

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

            Bug ID: 17414
           Summary: rhel7/ppc64: "stap -p4 -e 'probe nfsd.open{
                    println(fh) }'" semantic error
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com

On rhel7/ppc64 I see following semantic error:

.qa. 7.0 S ppc64 # stap --version
Systemtap translator/driver (version 2.7/0.158, rpm 2.7-1.mcermak.b6eb07f.el7)
Copyright (C) 2005-2014 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
enabled features: AVAHI LIBRPM LIBSQLITE3 NSS BOOST_SHARED_PTR
TR1_UNORDERED_MAP NLS DYNINST JAVA LIBVIRT LIBXML2
.qa. 7.0 S ppc64 # uname -r
3.10.0-123.6.3.el7.ppc64
.qa. 7.0 S ppc64 # 
.qa. 7.0 S ppc64 # 
.qa. 7.0 S ppc64 # stap -p4 -e 'probe nfsd.open{ println(fh) }' 
semantic error: not accessible at this address (pc: 0x18178) [man
error::dwarf]: identifier '$fhp' at
/usr/share/systemtap/tapset/linux/nfsd.stp:1100:16
(Continue reading)

mcermak at redhat dot com | 19 Sep 12:31 2014

[Bug runtime/17413] New: missing timer_create syscall in 32-on-64 mode

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

            Bug ID: 17413
           Summary: missing timer_create syscall in 32-on-64 mode
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com

Systemtap is missing timer_create syscall in 32-on-64 mode:

 7.0 S x86_64 # cat test.c
#include <sys/time.h>
#include <string.h>
#include <signal.h>
#include <time.h>
#include <sys/syscall.h>
#include <stdio.h>

int main()
{
    timer_t tid=0;
    syscall(__NR_timer_create, CLOCK_REALTIME, -1, &tid);
    return 0;
}

(Continue reading)

jistone at redhat dot com | 18 Sep 19:55 2014

[Bug translator/17410] New: let --remote optionally handle compilation from afar too

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

            Bug ID: 17410
           Summary: let --remote optionally handle compilation from afar
                    too
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: jistone at redhat dot com

Right now when using remote, you must either have a local environment for
compiling to the target, or enable a compile server for that.  But there may be
cases where the remote targets are already capable of compiling stap modules
themselves, and we could let them do so directly.

The user would still get to write their script locally however they like, and
can also get the fanout of running it on multiple --remote targets at once.

This would have similar questions as the compile server as to what to ship from
the user to remote -- at least the script and -I tapsets, and all the options
except remote itself.  But this wouldn't have the same security considerations
as the compile server, because --remote works as an authenticated user already.

A new --remote-compile option might be the trigger for this new behavior.

--

-- 
(Continue reading)

Santosh Shukla | 16 Sep 14:49 2014

[SYSTEMTAP/PATCH v2 0/6] RT aware systemtap patch set

Hi,

This is a v2 version of -rt aware systemtap patchset, tested for 3.14.12-rt9 and for 3.10.40-rt38 kernel version.
For v1->v2 related details refer [1]. Patchset based on stap upstream link [2] master branch.

Change summary;

v1->v2 :

- added Locking helper api. tested for -rt and voluntary mode, works fine.
- reverted v1 change of rd/wr lock with rcu to raw_spinlock in this patch, that
  is beacuse for rcu to effectively get in use in stap modules like utrace.c
and task_finder.c, require to make desing change in general. However it would
improve the performance,
- Removed v1's adder_map patch set, as it wasn't troubling -rt mode.

Test script used for testing :
/usr/local/stap/bin/stap -v testsuite/systemtap.examples/network/netdev.stp
/usr/local/stap/bin/stap -v testsuite/systemtap.examples/network/tcpdumplike.stp

Few other test example script used :
cat ../test-indent.stp
probe kernel.function("* <at> net/socket.c").call
{
                  printf ("%s -> %s\n", thread_indent(1), probefunc())
}
probe kernel.function("* <at> net/socket.c").return
{
                  printf ("%s <- %s\n", thread_indent(-1), probefunc())
}
(Continue reading)

dcb314 at hotmail dot com | 15 Sep 21:21 2014

[Bug runtime/17395] New: util.cxx:1120: bad switch statement ?

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

            Bug ID: 17395
           Summary: util.cxx:1120: bad switch statement ?
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: dcb314 at hotmail dot com

[util.cxx:1120] -> [util.cxx:1122]: (warning) Variable 'err_msg' is reassigned
a value before the old one has been used. 'break;' missing?

      switch (errno) // ignore EINVAL: invalid signal
      {
        case ESRCH:
          err_msg = "pid given does not correspond to a running process";
        case EPERM:
          err_msg = "invalid permissions for signalling given pid";
        default:
          err_msg = "invalid pid";
      }

Basic coding error. Suggest add break statements.

--

-- 
You are receiving this mail because:
(Continue reading)

mcermak at redhat dot com | 15 Sep 14:34 2014

[Bug runtime/17393] New: java.exp: ERROR: Cannot attach to module control channel

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

            Bug ID: 17393
           Summary: java.exp: ERROR: Cannot attach to module control
                    channel
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com

Running java.exp's singleparam.stp repeatedly on f20 shows that from time to
time (~ 50% of runs in my case) the testcase fails. In that case the testcase
produces an error and a zombie systemtap module is left in the kernel. This
never happens when stap is run in the verbose mode (-v). In verbose mode the
testcase seems to always pass:

=======
# lsmod | grep stap
# stap systemtap.apps/singleparam.stp -c "java singleparam >/dev/null 2>&1"
java("singleparam").class("singleparam").method("printMessage(int)") 42
java("singleparam").class("singleparam").method("printMessage(long)") 254775806
java("singleparam").class("singleparam").method("printMessage(double)") 3
java("singleparam").class("singleparam").method("printMessage(float)") 2345987
java("singleparam").class("singleparam").method("printMessage(byte)") 10
java("singleparam").class("singleparam").method("printMessage(boolean)") 1
java("singleparam").class("singleparam").method("printMessage(char)") 97
(Continue reading)

mcermak at redhat dot com | 15 Sep 13:07 2014

[Bug runtime/17392] New: fib.exp broken on rhel7 and f20

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

            Bug ID: 17392
           Summary: fib.exp broken on rhel7 and f20
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com

The fib.exp testcase works on RHEL6, but is broken on RHEL7 and f20, since
print_ubacktrace{,_brief}() doesn't return expected output there. It looks like
the user-level root cause is simply presence of the .return probe:

 7.0 S x86_64 # cat test.c 
void f3(void){}
void f2(void){f3();}
void f1(void){f2();}
void f0(void){f1();}

int main() {
        f0();
        return 0;
}
 7.0 S x86_64 # gcc -g test.c 
 7.0 S x86_64 # stap -e 'probe process.function("f3")
{print_ubacktrace_brief(); printf("\n")} probe process.function("f3").return
(Continue reading)

Brian Chrisman | 11 Sep 07:48 2014
Picon

[PATCH] proof of concept: systemtap/git differential code-coverage

Using systemtap and a git-diff hook, I implemented a poor
man's differential code coverage tool (roughly extracted from
a tool I built for use internally).  The script
testsuite/testAndRun generates and launches a systemtap script
defining userspace probes and then executes 'make check'.
At the end of the test, a report is output with identifiers
showing whether a added/modified line is:
a) coverage not available (no DWARF point)
b) covered but not executed
c) covered and executed by some test

example output from a recent commit I moved up to HEAD:
...
if test -n ""; then mail  < systemtap.sum; fi
make[1]: Leaving directory `/root/systemtap/testsuite'
cover_na       tapsets.cxx    1112 :                   || fi->descriptor) // ppc opd (and also undefined symbols)
cover_na       tapsets.cxx    1113 :                 continue;
cover_exec     tapsets.cxx    1111 :               if (!null_die(&fi->die) // already handled in query_module_dwarf()
cover_exec     tapsets.cxx    1114 :               if (dw.function_name_matches_pattern(fi->name, function_str_val))
---
 testsuite/testAndCover |   72 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 72 insertions(+), 0 deletions(-)
 create mode 100755 testsuite/testAndCover

diff --git a/testsuite/testAndCover b/testsuite/testAndCover
new file mode 100755
index 0000000..00bdd96
--- /dev/null
+++ b/testsuite/testAndCover
 <at>  <at>  -0,0 +1,72  <at>  <at> 
(Continue reading)

Stefan Hajnoczi | 9 Sep 17:23 2014
Picon

[PATCH] initscript: automatically detect uprobes dependency

systemtap-initscript scripts that rely on uprobes must be configured
with the --save-uprobes option.  This option saves the generated
uprobes.ko module and loads it when running the script.

The uprobes dependency information is actually available at compile time
so we can autodetect as follows:
1. Check if uprobes.ko was generated during compile
2. When uprobes.ko was generated, touch <name>.uprobes in the cache
   directory.
3. Add the staprun -u option if <name>.uprobes exists

It is no longer necessary to specify the --save-uprobes option in the
initscript configuration file, although doing so allowed.

Signed-off-by: Stefan Hajnoczi <stefanha <at> redhat.com>
---
 initscript/systemtap.in | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/initscript/systemtap.in b/initscript/systemtap.in
index 683734d..c8219cb 100755
--- a/initscript/systemtap.in
+++ b/initscript/systemtap.in
 <at>  <at>  -495,13 +495,16  <at>  <at>  compile_script () { # script checkcache
     return 1
   fi
   pushd "$tmpdir" &> /dev/null
-  logex $STAP -m "$1" -p4 -r $KRELEASE $opts "$f"
+  logex $STAP -m "$1" -p4 -r $KRELEASE --save-uprobes $opts "$f"
   ret=$?
(Continue reading)

Santosh Shukla | 9 Sep 09:08 2014

[SYSTEMTAP/PATCH 0/4] RT aware systemtap patch set

Hi,

I wanted to run systemtap on -rt kernel version 3.14.12-rt9 and noticed bunch of preemptible
bug_on.This is initial effort to make systemtap rt-aware. Tested on 3.14.12-rt
kernel.  Patchset based on stap upstream link [1], build on commit-id [2].
Patchset can work on master branch with little tweak in patch set.

I have also tested this patch set in 3.10.40-rt38 kernel noticed few preemptible
bug_on but those were coming from kernel and no improvement observed in
systemtap side.

Change summary -
- Replaced read lock with rcu_read_lock such that read_lock_irqsave lock substituion is
  rcu_read_lock + local_irq_save and for read_unlock_irqsave lock substitution is 
  local_irq_restore followed bu rcu_read_unlock.

- Replaced write_lock_irqsave/restore with raw_spinlock_irqsave/restore for -rt kernel.
  And for non-rt kernel those raw_ lock should get replaced by normal spin_lock.

- Replaced hlist api to rcu type api.

Test script used for testing :
/usr/local/stap/bin/stap -v testsuite/systemtap.examples/network/netdev.stp
/usr/local/stap/bin/stap -v testsuite/systemtap.examples/network/tcpdumplike.stp

Few other test example script used :
cat ../test-indent.stp
probe kernel.function("* <at> net/socket.c").call
{
	          printf ("%s -> %s\n", thread_indent(1), probefunc())
(Continue reading)

mcermak at redhat dot com | 8 Sep 17:15 2014

[Bug runtime/17362] New: no script-level local variables available in F20's kernel.function("do_execve")

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

            Bug ID: 17362
           Summary: no script-level local variables available in F20's
                    kernel.function("do_execve")
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com

No script-level local variables available in F20's
kernel.function("do_execve"). This changed between 3.13.9-200.fc20 and
3.15.10-201.fc20:

# uname -r; rpm -q systemtap
3.13.9-200.fc20.x86_64
systemtap-2.7-1.mcermak.e454243.fc20.x86_64
# stap -L 'kernel.function("do_execve")'
kernel.function("do_execve <at> fs/exec.c:1575") $filename:char const* $__argv:char
const* const* $__envp:char const* const*
#
# stap -e 'probe kernel.function("do_execve"){log(user_string($__argv[0]))}' -c
/bin/true
/bin/true
#

(Continue reading)


Gmane