mcermak at redhat dot com | 25 Mar 16:35 2015

[Bug server/18162] New: aarch64 compile server issue

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

            Bug ID: 18162
           Summary: aarch64 compile server issue
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: server
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com

Attempt to use localhost as a compile server fails on aarch64:

=======
# stap --use-server=127.0.0.1:49139 -v -e 'probe begin { log("hello"); exit()
}'
Using a compile server.
Pass 1: parsed user script and 103 library script(s) using
156224virt/40768res/6080shr/31552data kb, in 390usr/20sys/402real ms.
Pass 2: analyzed script: 1 probe(s), 2 function(s), 0 embed(s), 0 global(s)
using 156800virt/40768res/6080shr/32128data kb, in 0usr/0sys/8real ms.
Pass 3: translated to C into
"<server>/stap000000/stap_8c6be4bb35d99d58d100504093f86cd3_1064_src.c" using
156800virt/43136res/7232shr/32128data kb, in 0usr/0sys/1real ms.
Makefile:612: arch/aarch64/Makefile: No such file or directory
make: *** No rule to make target `arch/aarch64/Makefile'.  Stop.
WARNING: kbuild exited with status: 2
Pass 4: compiled C into "stap_8c6be4bb35d99d58d100504093f86cd3_1064.ko" in
(Continue reading)

dsmith at redhat dot com | 24 Mar 23:41 2015

[Bug tapsets/18159] New: the [nd_]syscall.ptrace probes need improvement

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

            Bug ID: 18159
           Summary: the [nd_]syscall.ptrace probes need improvement
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com

The [nd_]syscall.ptrace probes need improvement. Such as:

- no test case
- no 32-bit compat support
- support for newer ptrace requests, like: 

       PTRACE_PEEKSIGINFO (since Linux 3.10)                                    
       PTRACE_GETSIGMASK (since Linux 3.11)                                     
       PTRACE_SETSIGMASK (since Linux 3.11)

--

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

mcermak at redhat dot com | 23 Mar 08:56 2015

[Bug testsuite/18154] New: let's be more forgiving on ppc64le

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

            Bug ID: 18154
           Summary: let's be more forgiving on ppc64le
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: testsuite
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com

Created attachment 8205
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8205&action=edit
proposed patch

Commit bf952a76444755f3bf0b8f7deb808e2b6b2ce7ac removed --skip-badvars from
syscall.exp. Given the suboptimal quality of debuginfo on this architecture,
this causes many testsuite failures. Let's consider conditionally putting
--skip-badvars back.

For the same reason it might be helpful to use prologue searching by default on
this architecture in the testsuite.

Proposed patch attached. Thoughts?

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
(Continue reading)

mcermak at redhat dot com | 20 Mar 13:53 2015

[Bug testsuite/18151] New: chroot, getpid, getppid, gettid, iopl, lookup_dcookie, mincore need test coverage

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

            Bug ID: 18151
           Summary: chroot, getpid, getppid, gettid, iopl, lookup_dcookie,
                    mincore need test coverage
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: testsuite
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com

Syscalls chroot, getpid, getppid, gettid, iopl, lookup_dcookie, mincore need
test coverage. Please cover.

--

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

maxvt at bu dot edu | 18 Mar 21:13 2015

[Bug tapsets/18143] New: target_set tapset does not track threads created with clone()

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

            Bug ID: 18143
           Summary: target_set tapset does not track threads created with
                    clone()
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: maxvt at bu dot edu

Created attachment 8197
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8197&action=edit
tentative patch

I'm using systemtap to track system calls done by a specific process and its
descendants (e.g., sshd). Using ancient systemtap, the script works perfectly.
Using 2.6/0.159, no child process activity is picked up. After a little
debugging, it seems child processes are not being added to the target set.

Example probes:
probe syscall.execve {
    if (target_set_pid(pid())) {
        printf("t=%d p=%d (%s) execve (%s)\n", getjc(), pid(), execname(),
argstr)
    }
}
(Continue reading)

Stephane Chazelas | 17 Mar 22:22 2015
Picon

feature request: DWARF-based sizeof(), array_size(), typeof()

Hello,

recently, I found myself needing to loop over the elements of a
kernel array
(http://stackoverflow.com/questions/29034267/get-size-of-target-array-in-systemtap)

Though there are ways to get that information (parse symdata(),
use C code relying on internal APIs), none of them are
straighforward or ideal.

It would be nice if operators like sizeof(addr) (to retrieve the
size of a symbol at a given address) and array_size(addr) (to
retrieve the number of elements if that is an array). be added
to systemtap.

A typeof() one could be nice as well (especially if we can
combine it with  <at> cast).

What do you think?
Stephane

dsmith at redhat dot com | 17 Mar 19:28 2015

[Bug tapsets/6762] Some syscalls functions just wrappers for other syscalls

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

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from David Smith <dsmith at redhat dot com> ---
(In reply to Frank Ch. Eigler from comment #4)
> This problem periodically reoccurs; we will have to deal with it
> properly.  See bug #11263.

As part of all the syscall tapset work that's been done recently (bug #16716),
a fix to avoid syscall nesting has been developed (originally for bug #15219).
This fix involves use of the  <at> __syscall_gate() family of macros. This fix
basically says if we're in syscall.faccessat, but the syscall number isn't
__NR_faccessat, return.

Every known instance of this problem has been fixed. It is likely there are
problems with syscalls without a test program. We'll have to tackle these as we
continue work in this area.

I'm going mark this bug as resolved, and we'll just file individual bugs on
syscalls without test programs and fix nesting problems then.

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
(Continue reading)

Maxim Timchenko | 12 Mar 18:41 2015

Platform-dependent issues on "stable" (1.7.1) systemtap in Debian Wheezy

Hi all,

I'm looking at an issue with the stable version of systemtap (1.7.1)
on Wheezy and hitting an issue only when running on i686 (x86_64 works
fine) - a specific probe (tty_read) is apparently getting its
parameters wrong and gives a kernelspace memory access error. Looking
a bit further in, the tty driver structure within the probe (or when
hooking the corresponding n_tty_read kernel function) doesn't have the
correct magic set, so other members of the structure are probably
garbage too and dereferencing causes the error message. The tty_write
probe is working perfectly and the parameters look correct.

Does the Debian version work with a specific kernel version/arch, or
is it expected to work on any kernel package released by the distro? I
started with the latest and downgraded to what works for me on x86_64
without any improvement (3.2.63-2+deb7u2). I tried deleting the
.systemtap to clear up any temporary files (advice from a random
website).

Is it worth pursuing the resolution on the stable version, or should I
just give up the idea of using packaged versions and build the latest
version of systemtap, and perhaps the latest kernel too, on the same
machine and toolset?

Yours,
--

-- 
Max

dsmith at redhat dot com | 12 Mar 15:56 2015

[Bug tapsets/18122] New: [nd_]syscall.exec* probes need work

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

            Bug ID: 18122
           Summary: [nd_]syscall.exec* probes need work
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com

The [nd_]syscall.execve and [nd_]syscall.execveat probes are a bit odd and
could use a bit of work:

- For some reason, their 'argstr' convenience variables don't have commas
between arguments like every other syscall probe.
- They don't report the 'envp' argument.
- The [nd_]syscall.execve probes have no test case. This new test case can be
based on the existing execveat test case.

--

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

dsmith at redhat dot com | 12 Mar 15:45 2015

[Bug tapsets/18121] New: fallocate syscall support needs to be added

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

            Bug ID: 18121
           Summary: fallocate syscall support needs to be added
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com

Back in kernel v2.6.23, the fallocate() syscall was added by the following
kernel commit:

====
commit 97ac73506c0ba93f30239bb57b4cfc5d73e68a62
Author: Amit Arora <aarora <at> in.ibm.com>
Date:   Tue Jul 17 21:42:44 2007 -0400

    sys_fallocate() implementation on i386, x86_64 and powerpc

    fallocate() is a new system call being proposed here which will allow
    applications to preallocate space to any file(s) in a file system.
    Each file system implementation that wants to use this feature will need
    to support an inode operation called ->fallocate().
    Applications can use this feature to avoid fragmentation to certain
    level and thus get faster access speed. With preallocation, applications
    also get a guarantee of space for particular file(s) - even if later the
(Continue reading)

BR Chrisman | 12 Mar 06:32 2015
Picon

odd behavior in stap statement probes with varied wildcards

Description:
statement("* <at> <file>:<line>") *doesn't* find the probe point
statement("<function> <at> <file>:<line>") *does* find the probe point.
statement("* <at> <file>:*") *does* find the probe point (grepped)
statement("* <at> <file>:0,<line>") *does* find the probe point
statement("* <at> <file>:<line>,<line>) *does* find the probe point

Theory: Possible interaction bug with the wildcarding between function
specifier and line number specifier which is somehow overridden with
comma-separated line specifier or line-number wildcarding.

I'm a bit familiar with this code, so I can put some eyeballs on it.

---
This is a transcript that I've modified just to simplify the binary
name to 'Binary', the source file to 'foo.h', and the function name to
'myfunction' from their original (very unreadable) values.
---
[root <at> buildvm-2adb537a-8af2-4184-9f64-42c3a9329afa ~]# stap -v -e
'global tmp318; probe process("Binary").statement("* <at> */foo.h:0,366")
if (tmp318 == 0) { tmp318++; println(pp()); }'
Pass 1: parsed user script and 111 library script(s) using
207960virt/35752res/3164shr/32876data kb, in 170usr/10sys/183real ms.
Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 1
global(s) using 234888virt/63464res/3864shr/59804data kb, in
420usr/30sys/453real ms.
Pass 3: using cached
/root/.systemtap/cache/30/stap_30b7d2b815e7a2fe3fae6880268de171_1826.c
Pass 4: using cached
/root/.systemtap/cache/30/stap_30b7d2b815e7a2fe3fae6880268de171_1826.ko
(Continue reading)


Gmane