Wolfram Gettert | 23 Nov 19:58 2014
Picon

Systemtap un Ubuntu 14.04

Hi,
I am trying get Systemtap running on Ubuntu 14.04.

I am using the standard kernel 3.13.0-32-generic.
I have installed these
http://ddebs.ubuntu.com/pool/main/l/linux-lts-trusty/linux-image-3.13.0-32-generic-dbgsym_3.13.0-32.57~precise1_amd64.ddeb
pac debug symbols.

I tried two versions of systemtap.

This one installed as Debian package:
stap --version
Systemtap translator/driver (version 2.3/0.158, Debian version
2.3-1ubuntu1 (trusty))
Copyright (C) 2005-2013 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
enabled features: AVAHI LIBSQLITE3 NSS TR1_UNORDERED_MAP NLS

This one from git:
./stap --version
Systemtap translator/driver (version 2.7/0.158, commit
release-2.6-93-g0cf3720fbd15 + changes)
Copyright (C) 2005-2014 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
enabled features: TR1_UNORDERED_MAP NLS

I get the following error executing my probe listening for the open syscall.

mm <at> xubuntu:~/systemtap-2.7-7159/bin$ sudo stap
../../Downloads/correct/systemtap/strace-open.stp
(Continue reading)

Shane Wayne | 21 Nov 03:25 2014
Picon

Problems on glibc UTRACE

I've recently tap into malloc function of glibc, but I've encounter
some problems.
Firstly, I have install systemtap and glibc-dbg on Ubuntu 14.04(with
kernel 3.13 and UTRACE kernel flag default on).
The result show that, I can tap into
process("/lib/x86_64-linux-gnu/libc.so.6").function("malloc"), BUT,
the question is that, I can't get the right $bytes in this system, the
value I've got always like an pointer value start with 0x7f****. I've
tried the script on my own micro benchmark, with a single malloc
function invoke, the result also show that I can't get the right
parameters out, what's more, my micro benchmark triggered the tap
TWICE.
Secondly, I migrate to CentOS 6.6, with kernel
2.6.32-504.1.3.el6.x86_64 and UTRACE kernel flag default on, at this
time, I can get the right parameter $bytes out, but in my own micro
benchmark, the twice triggered problem also appear.

peter at peca dot dk | 19 Nov 14:51 2014

[Bug uprobes/17623] New: Sometimes probes fail to fire events when running against a multi-threaded application

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

            Bug ID: 17623
           Summary: Sometimes probes fail to fire events when running
                    against a multi-threaded application
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: uprobes
          Assignee: systemtap at sourceware dot org
          Reporter: peter at peca dot dk

Created attachment 7948
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7948&action=edit
The example program that triggers the behavior

I have the following test program (attached as testprog.c)

  #include <pthread.h>
  #include <unistd.h>

  #define WAIT_US 1

  void func1()
  {
  }

  void func2()
(Continue reading)

wcohen at redhat dot com | 18 Nov 23:50 2014

[Bug translator/17622] New: On aarch64 ./systemtap.base/listing_mode.exp fails to find any probe points for process.library("liblisting_mode.so").function("libfoo")

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

            Bug ID: 17622
           Summary: On aarch64  ./systemtap.base/listing_mode.exp fails to
                    find any probe points for
                    process.library("liblisting_mode.so").function("libfoo
                    ")
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: wcohen at redhat dot com

A significant portion of the test failures on aarch64 are due to stap -l not
listing any probe points for
process.library("liblisting_mode.so").function("*").  In the systemtap.log see
many entries like the following:

executing: stap -l process.library("liblisting_mode.so").function("libfoo")  -c 
 listing_mode
received: "child process exited abnormally"
expected:
"^process\("/root/systemtap_write/systemtap/testsuite/listing_mode"\).library\("/root/systemtap_write/systemtap/testsuite/liblisting_mode.so"\)\.function\("libfoo <at> [^:]+:54"\)$"
FAIL: listing_mode (process.library("liblisting_mode.so").function("libfoo") 
-c listing_mode)

Using the liblisting_mode.so shared library and liblisting_mode executable
(Continue reading)

fche at redhat dot com | 12 Nov 02:21 2014

[Bug translator/17587] New: too sensitive to duplicate globals across tapset files

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

            Bug ID: 17587
           Summary: too sensitive to duplicate globals across tapset files
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: fche at redhat dot com

It has been reported that the glib-supplied tapset files
{32,64}-gobject.stp are near-duplicates of one another,
specifically they contain identical

   global gtypes

If an end-user script causes both tapset files to be
processed, this results in

semantic error: conflicting global variables: identifier 'gtypes' at
/usr/share/systemtap/tapset/64-gobject.stp:1:8
        source: global gtypes
[...]

In this case, this error need not even be one: a single
global variable can be shared between the tapset files.
(If there were a type incompatibility, that would be
(Continue reading)

snehalphule | 3 Nov 12:42 2014
Picon

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

Hello,

I did reopen the bug, which is not related to x86, however I see similar 
issue on ppc64le architecture.
Please let me know if there are any suggestions.

Thanks,
Snehal

William Cohen | 2 Nov 22:02 2014
Picon

arm64 kprobes/systemtap support progress

Hi All,

Dave Long has been working on getting arm64 kprobes support merged into the upstream kernels.  The
kprobes64 branch of the git tree at 
https://git.linaro.org/people/dave.long/linux.git

I have been using systemtap to exercise the arm64 kprobes support and flush out any problems with them.  The
attached kernel patch fixes a couple problems observed in the arm64 kprobes:

- irq needs to be masked during single step
- the address to continue execution should be statically computed and not change

With the attached patch and recent correction to the systemtap runtime time.c for arm64. periodic.stp run
on arm64:

# ~/systemtap_write/install/bin/stap --all-modules  periodic.stp 
#monitoring timer periods (press control-c for output)
^C#type   function                                            period(us)     count
kernel  0xfffffdfffcaf2c50 [stap_41b9ddd4f103a617201d73e05       10008      1230
kernel  0xfffffdfffcaf3280 [stap_41b9ddd4f103a617201d73e05       20032       614
process xfsaild/dm-0(404)                                        50000       246
process rcu_sched(7)                                            159873        77
work_q  phy_state_machine                                      1000011        11
work_q  vmstat_update                                          1000009        11
work_q  vmstat_update                                          1000919        11
work_q  vmstat_update                                          1000010        11
work_q  vmstat_update                                          1000018        11
work_q  vmstat_update                                          1352511         8
work_q  vmstat_update                                          1512865         7
kernel  br_hello_timer_expired+0x0/0x90 [bridge]               1999999         5
(Continue reading)

Andriy Zharko | 25 Oct 15:19 2014
Picon

Systemtap smoke test fails on Ubuntu Server LTS 14.04.1 (Utopic)

Hello!

I install systemtap on my Ubuntu server using apy-get or build it
straight from systemtap's git repo, all looks fine. However, when
executing a simple smoke test, I get following errors:
===============================================================
$ sudo stap -v -e 'probe vfs.read {printf("read performed\n"); exit()}'
Pass 1: parsed user script and 106 library script(s) using
56160virt/33364res/4380shr/29708data kb, in 100usr/0sys/98real ms.
Pass 2: analyzed script: 1 probe(s), 1 function(s), 3 embed(s), 0
global(s) using 206536virt/185424res/6120shr/180084data kb, in
1410usr/80sys/1498real ms.
Pass 3: translated to C into
"/tmp/stapqyvuQN/stap_fed5d5a9ebf742dd24a5b0fcc8155bb5_1527_src.c" using
206536virt/185616res/6312shr/180084data kb, in 10usr/0sys/4real ms.
ld: BFD (GNU Binutils for Ubuntu) 2.24.90.20141014 internal error,
aborting at ../../bfd/elf-eh-frame.c line 1727 in
_bfd_elf_write_section_eh_frame

ld: Please report this bug.

scripts/Makefile.modpost:124: recipe for target
'/tmp/stapqyvuQN/stap_fed5d5a9ebf742dd24a5b0fcc8155bb5_1527.ko' failed
make[1]: ***
[/tmp/stapqyvuQN/stap_fed5d5a9ebf742dd24a5b0fcc8155bb5_1527.ko] Error 1
Makefile:1348: recipe for target 'modules' failed
make: *** [modules] Error 2
WARNING: kbuild exited with status: 2
Pass 4: compiled C into "stap_fed5d5a9ebf742dd24a5b0fcc8155bb5_1527.ko"
in 4890usr/860sys/5840real ms.
(Continue reading)

thepouar at gmail dot com | 23 Oct 03:02 2014

[Bug tapsets/6525] need utrace task-finder-based pid->execname, pid->cwd-path-name tables

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

thepouar at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|thepouar at gmail dot com          |

--

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

thepouar at gmail dot com | 23 Oct 03:01 2014

[Bug tapsets/6525] need utrace task-finder-based pid->execname, pid->cwd-path-name tables

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

thepouar at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thepouar at gmail dot com

--

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

thepouar at gmail dot com | 23 Oct 02:58 2014

[Bug tapsets/6525] need utrace task-finder-based pid->execname, pid->cwd-path-name tables

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

thepouar at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|thepouar at gmail dot com          |

--

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


Gmane