wcohen at redhat dot com | 28 May 20:01 2015

[Bug translator/18461] New: The code generated by tapset-netfilter.cxx for nf_hook_ops does not compile with linux-4.1.0-rc5 kernel

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

            Bug ID: 18461
           Summary: The code generated by tapset-netfilter.cxx for
                    nf_hook_ops does not compile with linux-4.1.0-rc5
                    kernel
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: wcohen at redhat dot com
  Target Milestone: ---

When reviewing the test resuts on an arm machine runing a linux-4.1-rc5 kernel
a number of the tests such as netfilter_summary_json.stp fail to compile. 
Below is a example output from from the systemtap.log:

TEST
PWD=/run/media/wcohen/wasteland/wcohen/systemtap_write/systemtap/testsuite/systemtap.examples/network
meta taglines 'test_check: stap -g -p4 netfilter_drop.stp TCP 1' tag
'test_check' value 'stap -g -p4 netfilter_drop.stp TCP 1'
attempting command stap -g -p4 netfilter_drop.stp TCP 1
OUT /tmp/stapEqKFr7/stap_74a85d0b748d91faedb84473b46a3398_14384_src.c:2709:1:
error: initialization from incompatible pointer type [-Werror]
 .hook = enter_netfilter_probe_0,
 ^
/tmp/stapEqKFr7/stap_74a85d0b748d91faedb84473b46a3398_14384_src.c:2709:1:
(Continue reading)

Lentes, Bernd | 28 May 14:06 2015
Picon

no access to local variables in function

Hi,

i'm new to systemtap. I try to check some local variables of kernel functions. I have a SLES 10 SP4, kernel
2.6.16.60-0.103.1-smp. I'm using systemtap 0.8.
I'm following the instructions from
https://sourceware.org/systemtap/SystemTap_Beginners_Guide/targetvariables.html .

If I try to use the example from this page I get:
idcc-devel:~/systemtap # stap -L 'kernel.function("vfs_read")'
kernel.function("vfs_read <at> fs/read_write.c:248")

Checking other functions with local variables also does not work:
idcc-devel:~/systemtap # stap -L 'kernel.function("local_bh_enable")'
kernel.function("local_bh_enable <at> kernel/softirq.c:139")

idcc-devel:~/systemtap # stap -L 'kernel.function("__tasklet_schedule")'
kernel.function("__tasklet_schedule <at> kernel/softirq.c:224")

idcc-devel:~/systemtap # stap -L 'kernel.function("tasklet_kill_immediate")'
kernel.function("tasklet_kill_immediate <at> kernel/softirq.c:439")

I don't see any local variable. What can I do ?

Btw: is there a chance to monitor the variables of a blacklisted function ?

Thanks.

Bernd

--
(Continue reading)

mcermak at redhat dot com | 28 May 09:47 2015

[Bug runtime/18460] New: tracepoint_onthefly.exp kernel crash

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

            Bug ID: 18460
           Summary: tracepoint_onthefly.exp kernel crash
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com
  Target Milestone: ---

With recent upstream bits I see tracepoint_onthefly.exp causing kernel crash on
ppc64(le/be) pretty reliably. E.g. using release-2.7-157-g35bd6e1548e9 (or in
beaker using older 22cabe6) on top of 3.10.0-229.el7.ppc64 I see:

=======
ibm-p730-06-lp2 login: [1645691.300056] INFO: rcu_sched detected stalls on
CPUs/tasks: { 0 2 3 4 5 6 7 8 9 10 11 12
[1645691.300159] Task dump for CPU 0:                                           
[1645691.300166] swapper/0       R  running task        0     0      0
0x00000000
[1645691.300180] Call Trace:                                                    
[1645691.300194] [c00000000130b840] [0005d8af9a1ddff2] 0x5d8af9a1ddff2
(unreliable)
[1645691.300208] [c00000000130ba10] [0000000022002082] 0x22002082               
[1645691.300218] Task dump for CPU 2:                                           
[1645691.300225] swapper/2       R  running task        0     0      1
(Continue reading)

fche at redhat dot com | 26 May 21:48 2015

[Bug translator/18455] New: const_folder::visit_binary_expression hurting type inference

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

            Bug ID: 18455
           Summary: const_folder::visit_binary_expression hurting type
                    inference
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: fche at redhat dot com
  Target Milestone: ---

% stap -p2 -e 'probe oneshot { println(i+0) }'

... should work, and print 0.  But the const_folder logic elides the "+0" part
of that expression without passing on the type inference (i <= pe_long).

--

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

Athira | 20 May 14:21 2015
Picon

[PATCH] Add entry for ppc64le in arch list

A few tests fails in ppc64le with error:

========
parse error: expected 'probe', 'global', 'function', or '%{'^M
         saw: identifier 'ERROR' at <input>:22:43^M
      source:     %( arch == "ppc64le"            %? %: ERROR %)^M
                                                        ^^M
^M
1 parse error.^M
Pass 1: parse failed.  [man error::pass1]^M
FAIL: preprocessor basic ops
=========

This is because ppc64le is not added to arch list in systemtap.exp .
cmd_parse.exp also fails with similar error for arch.  Modifying the 
code for ppc64le.

Signed-off-by: Athira Rajeev <atrajeev <at> in.ibm.com>
---
  testsuite/lib/systemtap.exp | 1 +
  1 file changed, 1 insertion(+)

diff --git a/testsuite/lib/systemtap.exp b/testsuite/lib/systemtap.exp
index 8b99d37..fc91ca6 100644
--- a/testsuite/lib/systemtap.exp
+++ b/testsuite/lib/systemtap.exp
 <at>  <at>  -432,6 +432,7  <at>  <at>  proc normalize_arch { arch } {
      if {$arch == "armv7l"} then {return "arm"}
      if {$arch == "armv7lh"} then {return "arm"}
      if {$arch == "aarch64"} then {return "arm64"}
(Continue reading)

Felix Lu | 19 May 21:46 2015
Picon

[PATCH] systemtap language reference man page

Hi everyone,

I am a new intern and this patch contains a man page for the
language reference.

----
Felix

Signed-off-by: Felix Lu <flu <at> redhat.com>
---
 man/Makefile.am |   2 +-
 man/Makefile.in |  11 ++-
 man/stapref.1   | 216 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 222 insertions(+), 7 deletions(-)
 create mode 100644 man/stapref.1

diff --git a/man/Makefile.am b/man/Makefile.am
index dcff7b5..3f656bf 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
 <at>  <at>  -4,7 +4,7  <at>  <at> 
 AUTOMAKE_OPTIONS = no-dist foreign subdir-objects

 man_MANS = stapprobes.3stap stapfuncs.3stap stapvars.3stap stapex.3stap \
-	dtrace.1 stap-merge.1 stappaths.7 stapsh.8 systemtap.8
+	dtrace.1 stap-merge.1 stappaths.7 stapsh.8 systemtap.8 stapref.1

 # NB: this doesn't work, apparently because make doesn't like
 # file names with :: in them, misinterpreting them as some kind
diff --git a/man/Makefile.in b/man/Makefile.in
(Continue reading)

fche at redhat dot com | 19 May 17:46 2015

[Bug translator/18431] New: runtime function overloading facility

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

            Bug ID: 18431
           Summary: runtime function overloading facility
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: fche at redhat dot com
  Target Milestone: ---

It turns out to be necessary to have a facility that allows end-user scripts to
call generic functions like jstack(), while multiple alternative
implementations available in the tapset library.  The method of choosing
between the alternatives must be done at run-time (since it's run-time state
such as "which VM is this thread running in?" that decides), so we're talking
about a control-flow extension rather than translate-time processing like c++
overloading.

Possible syntax at call site: foo() - i.e., no visible change.

Possible syntax at definitions:
   function foo () {
      ...
      ... if (condition) next; ...
      ...
   }
(Continue reading)

fche at redhat dot com | 15 May 16:51 2015

[Bug translator/18415] New: .callee* .return probes

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

            Bug ID: 18415
           Summary: .callee* .return probes
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: fche at redhat dot com
  Target Milestone: ---

We overlooked the usefulness of .callee*.return probes; supporting .return
there would let us use entry/exit tracers like para-callgraph.stp.

--

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

jlebon at redhat dot com | 13 May 22:31 2015

[Bug runtime/17461] probing process.end crashes on busy systems

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

--- Comment #4 from Jonathan Lebon <jlebon at redhat dot com> ---
Created attachment 8312
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8312&action=edit
dmesg.log

This is still an issue on the latest f20 3.19.5 with the latest git stap.
Interestingly, adding debug statements in utrace_free() confirms that the crash
does not happen there, but the rest of the stack is still very similar (showing
a backtrace coming from exit() related calls).

--

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

mcermak at redhat dot com | 12 May 07:58 2015

[Bug tapsets/18398] New: The {get,set}_thread_area syscalls need tapset support and test coverage

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

            Bug ID: 18398
           Summary: The {get,set}_thread_area syscalls need tapset support
                    and test coverage
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com
  Target Milestone: ---

Syscalls {get,set}_thread_area need tapset support and test coverage.

--

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

mcermak at redhat dot com | 11 May 10:45 2015

[Bug tapsets/18395] New: Syscalls {get,set}_robust_list need tapset handler and test coverage

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

            Bug ID: 18395
           Summary: Syscalls {get,set}_robust_list need tapset handler and
                    test coverage
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com
  Target Milestone: ---

The {get,set}_robust_list syscalls need tapset support and test coverage.

--

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


Gmane