Zoltan Kiss | 26 Jun 20:58 2015

process().statement() doesn't seem to work

Hi,

I want to use systemtap to figure out the local variables in a function 
where something goes fishy. The function's code is here:

http://dpdk.org/browse/dpdk/tree/lib/librte_pmd_ixgbe/ixgbe_rxtx.c?id=v1.7.1#n1313

It's a receive function of DPDK's userspace poll mode driver, so it's 
called in an infinite loop. When I try this, it appers to work:

probe 
process("/usr/sbin/ovs-vswitchd").function("ixgbe_recv_scattered_pkts").return 
{
   log($$locals)
   exit();
}

The output is:

rxq=0x7fff852ee000 rx_ring=? rxdp=? sw_ring=? rxe=? first_seg=? 
last_seg=? rxm=? nmb=? rxd={...} dma=? staterr=? hlen_type_rss=? rx_id=? 
nb_rx=0x0 nb_hold=0x0 data_len=? pkt_flags=?

But it doesn't show most of the variables I need. It returns nb_rx=0, so 
I know where are the two points where things can go wrong, but I can't 
see the output of those variables (staterr and nmb)

When I try to define the probe as this:

probe 
(Continue reading)

dsmith at redhat dot com | 25 Jun 17:23 2015

[Bug tapsets/18598] New: staprun markers don't exist

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

            Bug ID: 18598
           Summary: staprun markers don't exist
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
  Target Milestone: ---

While working on bug #18577 and going through the semantic errors that 'stap
-vv -l **' produces, I noticed that I was getting errors from the
stap_staticmarkers.stp tapset. This tapset provides probe aliases for markers
built into stap and staprun.

Markers exist in stap:

====
# stap -l 'process("stap").mark("*")'
process("/usr/local/bin/stap").mark("benchmark")
process("/usr/local/bin/stap").mark("benchmark__end")
process("/usr/local/bin/stap").mark("benchmark__start")
process("/usr/local/bin/stap").mark("benchmark__thread__end")
process("/usr/local/bin/stap").mark("benchmark__thread__start")
process("/usr/local/bin/stap").mark("cache__add__module")
process("/usr/local/bin/stap").mark("cache__add__source")
(Continue reading)

mcermak at redhat dot com | 25 Jun 13:00 2015

[Bug tapsets/18597] New: long_arg() doesn't correctly handle negative values in 32-on-64 environment

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

            Bug ID: 18597
           Summary: long_arg() doesn't correctly handle negative values in
                    32-on-64 environment
           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: ---

Currently (15f1b3dd85f3) long_arg() doesn't correctly handle negative values in
compat tasks:

=======
 7.1 S x86_64 # gcc -g systemtap.syscall/aio.c -m32
 7.1 S x86_64 # stap -g -e 'probe
kernel.function("compat_sys_io_submit"){printf("%d %d %d\n",
 <at> __compat_long($nr), __int32($nr), %{ /* pure */ _stp_is_compat_task() %})}' -c
./a.out
1
1 1 1
1 1 1
-1 -1 1
1 1 1
 7.1 S x86_64 # stap -g -e 'probe
(Continue reading)

jistone at redhat dot com | 24 Jun 22:30 2015

[Bug uprobes/12275] uretprobes break exception handling

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

--- Comment #16 from Josh Stone <jistone at redhat dot com> ---
I just realized the obvious fact that this is really breaking *all* unwinding,
not just exceptions.  So print_ubacktrace() will end at the uretprobe
trampoline, and _caller_match() used by .callee probes will be disrupted too.

Perhaps those cases could poke around in kernel memory to find the true return
address.  The old utrace-based uprobes.ko had uprobe_get_pc(), and
runtime/stack.c conditionally uses this, but I think even that only worked for
the first unwind level.

--

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

jistone at redhat dot com | 22 Jun 22:47 2015

[Bug translator/18579] New: autocast <at> entry values

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

            Bug ID: 18579
           Summary: autocast  <at> entry values
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: jistone at redhat dot com
  Target Milestone: ---

From PR13664:

 <at> entry is similar [to saved $vars], but harder since the expression can be
anything.  I think it may need some kind of proxy "type" linking back to the
original expression, to be updated whenever that is resolved.

--

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

jistone at redhat dot com | 22 Jun 22:45 2015

[Bug tapsets/18578] New: autocast function parameters

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

            Bug ID: 18578
           Summary: autocast function parameters
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: jistone at redhat dot com
  Target Milestone: ---

From PR13664:

* If a dwarf-typed variable is passed as a function parameter, treat it like
template/generic programming and create a separate instance of that function.
- Functions with explicit typing like :long and :string could use :dwarf for
this special behavior.  Embedded-C functions shouldn't be allowed to use :dwarf
though.  (You're writing C, so cast it yourself, guru.)
- This function-forking will probably duplicate a lot, but we already have
mechanisms to recombine dupes in pass-3.

--

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

dsmith at redhat dot com | 22 Jun 20:25 2015

[Bug testsuite/18577] New: on rhel7, listing_mode_sanity.exp always gets a failure when doing 'stap -l **'

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

            Bug ID: 18577
           Summary: on rhel7, listing_mode_sanity.exp always gets a
                    failure when doing 'stap -l **'
           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: ---

On all RHEL7 architectures (x86_64, ppc64, and s390x), the
listing_mode_sanity.exp test case always gets a failure when doing 'stap -l
**':

====
FAIL: listing_mode_sanity (stap -l ** exited badly)
====

At first I thought this was because of tapset errors - but the tapsets don't
have any errors on x86_64 RHEL7. So, I went a bit further. The failure occurs
because the command is taking too long. The testsuite uses an rc file to ensure
that systemtap doesn't take too long. So, in effect, when doing a 'stap -l **'
we are really doing the following the following:

====
(Continue reading)

netfuzzer at yandex dot com | 22 Jun 18:05 2015

[Bug dyninst/18576] New: testing bugzilla

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

            Bug ID: 18576
           Summary: testing bugzilla
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: critical
          Priority: P2
         Component: dyninst
          Assignee: systemtap at sourceware dot org
          Reporter: netfuzzer at yandex dot com
  Target Milestone: ---

wwwwwwdd

--

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

mcermak at redhat dot com | 22 Jun 12:14 2015

[Bug tapsets/18571] New: Tapset support and test coverage for bpf and seccomp syscalls.

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

            Bug ID: 18571
           Summary: Tapset support and test coverage for bpf and seccomp
                    syscalls.
           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 bpf syscall needs tapset support and test coverage. Syscall seccomp needs
test coverage.

--

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

dsmith at redhat dot com | 19 Jun 20:23 2015

[Bug testsuite/18563] New: on ppc64, the mbrwatch.stp example script fails when tested

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

            Bug ID: 18563
           Summary: on ppc64, the mbrwatch.stp example script fails when
                    tested
           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: ---

On ppc64, the mbrwatch.stp example script fails to run when tested by the
check.exp test case. Here's the relevant output from the log file:

====
attempting command stap mbrwatch.stp -c "dd of=/dev/null count=1 if=/dev/`grep
-v major /proc/partitions | grep . | awk '{print $4}' | head -1`"
OUT dd: failed to open '/dev/sr0': No medium found
WARNING: Child process exited with status 1
WARNING: /usr/local/bin/staprun exited with status: 1
Pass 5: run failed.  [man error::pass5]
child process exited abnormally
RC 1
FAIL: systemtap.examples/io/mbrwatch run
====

(Continue reading)

dsmith at redhat dot com | 19 Jun 20:07 2015

[Bug testsuite/18562] New: the listing_mode.exp test case has lots of errors on systems without uprobes

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

            Bug ID: 18562
           Summary: the listing_mode.exp test case has lots of errors on
                    systems without uprobes
           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: ---

On rhel7 s390x (3.10.0-229.el7.s390x), the listing_mode.exp test case has 112
unexpected errors:

====
FAIL: listing_mode
(process.library("liblisting_mode.so").function("libfoo").callee("libbar")  -c
listing_mode)
FAIL: listing_mode
(process.library("liblisting_mode.so").function("libfoo").callee("libbar")  -c
./listing_mode)
FAIL: listing_mode
(process.library("liblisting_mode.so").function("libfoo").callee("libbar")  -c
EXEFULLPATH)
FAIL: listing_mode
(process("listing_mode").library("liblisting_mode.so").function("libfoo").callee("libbar")
(Continue reading)


Gmane