dsmith at redhat dot com | 3 Feb 16:11 2016

[Bug runtime/19560] New: flight recorder mode intermittently fails

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

            Bug ID: 19560
           Summary: flight recorder mode intermittently fails
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
  Target Milestone: ---

While doing some regression testing, I noticed that the
systemtap.base/flightrec4.exp test case is failing intermittently.

The test is supposed to start up stap in the background, writing to a file
called flightrec4.out.0. The test case then sends 3 USR2 signals to stapio, to
make stapio switch output to flightrec4.out.1, flightrec4.out.2,
flightrec4.out.3. When the test fails, the output gets sent instead to:
flightrec4.out.0, flightrec4.out.1, flightrec4.out.NUM, flightrec4.out.NUM+1,
where NUM is a large number like 54681. Sometimes stapio seems to exit before
creating the last output file.

At first I thought the problem might be with the test case itself, but after
updating it I've found that isn't the case.

The failures happen quite randomly, I get about 1 failure per 10 test case
runs.
(Continue reading)

dsmith at redhat dot com | 29 Jan 17:53 2016

[Bug testsuite/19537] New: the parseok/semko.stp test case always fails

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

            Bug ID: 19537
           Summary: the parseok/semko.stp test case always fails
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: testsuite
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
  Target Milestone: ---

The parseok/semko.stp test case is really a shell script that tries to parse
all the semko test files, to ensure that it is semantic (elaboration) checks
that fail, not parse errors. So, it runs 'stap -p1' on all the semko tests.
But, this isn't quite enough and the test always fails. Here's the tail of
systemtap.log:

====
parse error: embedded expression code in unprivileged script; need stap -g
        saw: embedded-code at
/root/rhel6/testsuite/../../src.copy/testsuite/../testsuite/semko/global_access.stp:8:11
     source:   println(%{ /* pragma:read:var */ STAP_GLOBAL_GET_var() %})
                       ^^
====

So, the test fails because semko/global_access.stp needs '-g', not because the
script can't be parsed. In addition, the test appears to stop on the first
(Continue reading)

dsmith at redhat dot com | 29 Jan 17:09 2016

[Bug translator/19536] New: kretprobe data-pouch type issue

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

            Bug ID: 19536
           Summary: kretprobe data-pouch type issue
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
  Target Milestone: ---

The testsuite/semok/kretprobe-data.stp testcase seems to think that $VAR$
(should work in return probes, but they don't seem to.

Here's printing '$path' (which works) and '$path$' (which doesn't). '$path$$'
also doesn't work.

====
# stap -p2 -e 'probe kernel.function("kern_path").return { println($path) }'
# global embedded code
%{
static void *
_kretprobe_data(struct kretprobe_instance *pi, size_t offset, size_t length)
{
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,25)
        size_t end = offset + length;
        if (end > offset && pi && end <= pi->rp->data_size)
(Continue reading)

mcermak at redhat dot com | 27 Jan 20:38 2016

[Bug runtime/19525] New: script doesn't finish in bulk mode

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

            Bug ID: 19525
           Summary: script doesn't finish in bulk 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
  Target Milestone: ---

It turns out that commit 62d2a73ee995739eeaa15e4d495f0452b589f30e caused a
regression on RHEL6 (not on RHEL7). Using stap from current upstream sources,
following script will never finish:

stap -ve 'probe begin { log("hey") exit() }'

The bulk mode needs to be in use to reproduce.

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
Masanari Iida | 27 Jan 04:18 2016
Picon

Failed to compile after dabd71bb2bf with gcc 4.8.3

After following commit merged into main tree,
it started to fail compiling systemtap with gcc 4.8.3 (on Fedora 20, x86_64),

commit dabd71bb2bfae4154229af4576771c788da0604a
Author: Mark Wielaard <mjw <at> redhat.com>
Date:   Sun Jan 24 20:59:13 2016 +0100

    Use -Wextra. Fix some warnings.

-- Error messages --

  CXX      stap-rpm_finder.o
rpm_finder.cxx:205:1: error: unused parameter ‘sess’ [-Werror=unused-parameter]
 missing_rpm_list_print (systemtap_session &sess, const char* rpm_type)
 ^
rpm_finder.cxx:205:1: error: unused parameter ‘rpm_type’
[-Werror=unused-parameter]
rpm_finder.cxx:232:1: error: unused parameter ‘sess’ [-Werror=unused-parameter]
 find_debug_rpms (systemtap_session &sess, const char * filename)
 ^
rpm_finder.cxx:232:1: error: unused parameter ‘filename’
[-Werror=unused-parameter]
rpm_finder.cxx:242:5: error: unused parameter ‘sess’ [-Werror=unused-parameter]
 int find_devel_rpms(systemtap_session &sess, const char * filename)
     ^
rpm_finder.cxx:242:5: error: unused parameter ‘filename’
[-Werror=unused-parameter]
cc1plus: all warnings being treated as errors
make[2]: *** [stap-rpm_finder.o] Error 1

(Continue reading)

dsmith at redhat dot com | 26 Jan 16:17 2016

[Bug translator/19521] New: the "private" keyword support has made error messages less useful

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

            Bug ID: 19521
           Summary: the "private" keyword support has made error messages
                    less useful
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
  Target Milestone: ---

====
# stap -ve 'probe begin { log(egid2()) }'
Pass 1: parsed user script and 112 library script(s) using
237668virt/36508res/7440shr/29392data kb, in 170usr/60sys/501real ms.
semantic error: unresolved function (similar: __global_egid, __global_gid,
__global_euid, __global_ns_egid, __global_pid): identifier 'egid2' at
<input>:1:19
        source: probe begin { log(egid2()) }
                                  ^

Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s)
using 238468virt/37544res/7704shr/30184data kb, in 10usr/0sys/21real ms.
Pass 2: analysis failed.  [man error::pass2]
====

(Continue reading)

dsmith at redhat dot com | 22 Jan 21:58 2016

[Bug runtime/19513] New: on rhel7 s390x, probing process.function("main").return causes the target to get an illegal instruction

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

            Bug ID: 19513
           Summary: on rhel7 s390x, probing
                    process.function("main").return causes the target to
                    get an illegal instruction
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
  Target Milestone: ---

On RHEL 7.2 (3.10.0-327.el7.s390x), the global_var.exp testcase has several
failures:

====
Running ../../src/testsuite/systemtap.base/global_var.exp ...
PASS: global_var-m64
FAIL: global_var-m31
PASS: global_var-m64-O
FAIL: global_var-m31-O
PASS: global_var-m64-O2
FAIL: global_var-m31-O2
====

As you can see, they all relate to probing 31-bit executables. The problem
(Continue reading)

dsmith at redhat dot com | 21 Jan 20:52 2016

[Bug translator/19510] New: the "private" keyword support has made -p1 output less useful

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

            Bug ID: 19510
           Summary: the "private" keyword support has made -p1 output less
                    useful
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
  Target Milestone: ---

As mentioned in bug #19136 comment #2, commit 38bf68a introduced the "private"
keyword. This works, but had the side effect of changing parser output. With
commit 38bf68a, you'll see this:

====
# stap -p1 ../src/testsuite/buildok/array_size.stp | head -n 11
# parse tree dump
# file ../src/testsuite/buildok/array_size.stp
global __global_a[1]
global __global_b[100000]
global __global_c
probe begin{
(a[42, "foobar"]) = ("Hello World!");
(b["foo", "bar", "baz", 42]) = (314159265);
(c[42]) = (161803399);
(Continue reading)

William Cohen | 21 Jan 01:30 2016
Picon
Gravatar

Unsuccessful attempts get aarch64 kernel backtraces support

I found that the aarch64 kernel are always built with framepointers,
so unwinding the aarhc64 kernel stack should be trivial.  However, it
doesn't currenlty work in systemtap. The systemtap runtime appears to
be currently trying to use the dwarf unwinding and that isn't working
on aarch64.  The userspace dwarf-based backtrace DOES work:

[root <at> apm-mustang-ev3-01 ~]# more backtrace_test.c
#include <stdlib.h>

int c(){ return 0;}
int b(){return c();}
int a(){return b();}

int main(int argc, char* argv[])
{
  exit(a());
}
[root <at> apm-mustang-ev3-01 ~]# gcc -g -o backtrace_test backtrace_test.c 
[root <at> apm-mustang-ev3-01 ~]# ./systemtap_write/install/bin/stap -e 'probe
process("./backtrace_test").function("c") {print_ubacktrace();}' -c ./backtrace_test
 0x4005c0 : c+0x0/0x8 [/root/backtrace_test]
 0x4005d4 : b+0xc/0x14 [/root/backtrace_test]
 0x4005e8 : a+0xc/0x14 [/root/backtrace_test]
 0x400604 : main+0x14/0x18 [/root/backtrace_test]
 0x3ffb037f68c [/usr/lib64/libc-2.22.so+0x1f68c/0x190000]
WARNING: Missing unwind data for a module, rerun with 'stap -d /usr/lib64/libc-2.22.so'

However, things do not work so well for the kernel backtraces on
aarch64 machine get the very limited:

(Continue reading)

fche at redhat dot com | 20 Jan 20:37 2016

[Bug documentation/19502] New: extend stap.1 with documentation overview

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

            Bug ID: 19502
           Summary: extend stap.1 with documentation overview
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: documentation
          Assignee: systemtap at sourceware dot org
          Reporter: fche at redhat dot com
  Target Milestone: ---

It would be nice to have [man stap] be a good starting point for finding all
stap-related information.  We have a nice "SEE ALSO" section at the very
bottom, but it's not very helpful.  We should have a new section near the front
that describes the other man pages (esp. stapprobes for $context vars),
families (function::*, tutorial/guides), and examples, so users can become
aware of the wealth of information and where to look.  (See also [man perl] and
[man zsh].)

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
dsmith at redhat dot com | 20 Jan 18:44 2016

[Bug translator/19500] New: .callee test failures

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

            Bug ID: 19500
           Summary: .callee test failures
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
  Target Milestone: ---

On RHEL7 s390x (3.10.0-327.el7.s390x), the callee.exp testcase gets the
following failures:

====
Running ../../src/testsuite/systemtap.base/callee.exp ...
FAIL: callee (inlined - probing .callee(foo).call)
FAIL: callee (reloc - listing shlib foo .callees)

                === systemtap Summary ===

# of expected passes            31
# of unexpected failures        2
====

But, in addition .callee causes lots of failures in the listing_mode.exp
testcase:
(Continue reading)


Gmane