headers
Frank Ch. Eigler | 1 Mar 2011 15:43
Picon
Favicon
Gravatar

Re: ERROR: Build-id mismatch

Hi -

On Tue, Mar 01, 2011 at 07:48:53PM +0530, deepak.venkatesh <at> wipro.com wrote:
>     I am trying to execute the following sample.stp script.
> global count=0
> probe kernel.function("open") {
>   count++
>   printf( "sys_sync called %d times, currently by pid %d\n", count,
> pid());
> }

OK.  (I didn't know there was a function named "open".)

> I am getting the following error:
> [...]
> ERROR: Build-id mismatch: "kernel" vs. "vmlinux-2.6.35-26-generic" byte
> 0 (0x9e vs 0x61) rc 0 0 

> The steps I followed for installing systemtap are:
> 1. Downloaded and installed following packages:
> linux-image-2.6.35-26-generic_2.6.35-26.46~utrace0_i386.deb,
> linux-headers-2.6.35-26_2.6.35-26.46~utrace0_all.deb,
> linux-headers-2.6.35-26-generic_2.6.35-26.46~utrace0_i386.deb and
> linux-image-2.6.35-26-generic-dbgsym_2.6.35-26.46_i386.ddeb in the same
> order.

The problem is that the ~utrace0 PPA does not include a matching ddeb
file, which means that the kernel debuginfo that systemtap has found
does not match the kernel that you're actually running.  Either the
PPA would need to ship .ddeb's, or you might have to hand-rebuild the
(Continue reading)

Permalink | Reply | 0 comments |
headers
jistone at redhat dot com | 1 Mar 2011 23:53
Favicon

[Bug translator/12139] SDT V3 fails with structs that are only declared

http://sourceware.org/bugzilla/show_bug.cgi?id=12139

Josh Stone <jistone at redhat dot com> changed:

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

--- Comment #2 from Josh Stone <jistone at redhat dot com> 2011-03-01 22:53:20 UTC ---
The sdt.h shipped with 1.4 works fine.

--

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
Roland McGrath | 2 Mar 2011 08:51
Picon
Favicon

glibc with probes

At http://koji.fedoraproject.org/scratch/roland/task_2877130/
you can find a build of the Fedora 15 glibc modified to add
the sdt.h probes for setjmp/longjmp and Rayson's pthread probes.
I've used this for some trivial manual tests of the setjmp/longjmp probes.

I hope the probes will be in the real Fedora 15 glibc before it's released,
but we'll have to see how that goes.

Thanks,
Roland
Permalink | Reply | 0 comments |
headers
roland at gnu dot org | 3 Mar 2011 02:26
Favicon

[Bug translator/12536] New: sdt v>=2 argument parsing can't parse '4+4(%esp)'

http://sourceware.org/bugzilla/show_bug.cgi?id=12536

           Summary: sdt v>=2 argument parsing can't parse '4+4(%esp)'
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: scox <at> redhat.com
        ReportedBy: roland <at> gnu.org
                CC: systemtap <at> sources.redhat.com

systemtap-1.4-3.fc15.x86_64

I have the glibc with sdt probes installed, you can get it from
http://koji.fedoraproject.org/scratch/roland/task_2877130/ (though that may
expire in a few days).  Both glibc.x86_64 and glibc.i686 rpms from there are
installed.

I used this script:

probe process("/lib*/libc.so.*").mark("*jmp*") { printf("%s(%p, %d) from PC %p:
%s\n", $$name, $arg1, $arg2, $arg3, sprint_ubacktrace()); }

That was in -e, along with -d .../setjmp --ldd where .../setjmp is an i686
executable (and -c .../setjmp was at the end).

This produced:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Roland McGrath | 3 Mar 2011 02:30
Picon
Favicon

Re: [Bug translator/12536] New: sdt v>=2 argument parsing can't parse '4+4(%esp)'

I filed this PR when I hit problems trying to develop a test case for the
new setjmp/longjmp probes.  The probe argument in glibc is not going to
change, so I think this needs to be fixed before a test case can pass for
i686.  I think I'll try to develop the full test suite case and get it
working on x86-64, where there won't be this problem because it doesn't
happen to come up in those probe arguments.

For reference, here is the program I was using when I filed that PR.

#include <stdio.h>
#include <setjmp.h>

struct env
{
  jmp_buf jmp;
};

struct env saved;

void __attribute__ ((noinline))
bar (struct env *env, int x)
{
  if (x == 0)
    siglongjmp (env->jmp, 1);
}

void __attribute__ ((noinline))
foo (void)
{
  if (sigsetjmp (saved.jmp, 1) == 0)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Zhiwei Ying | 3 Mar 2011 08:29
Picon

firmware tracing

Hi,

Has anyone thought about using systemtap to trace firmware code? Any
information?

Thanks,
Zhiwei
Permalink | Reply | 1 comment |
headers
dsmith at redhat dot com | 3 Mar 2011 19:26
Favicon

[Bug tapsets/12470] Fix _wait4_opt_str

http://sourceware.org/bugzilla/show_bug.cgi?id=12470

--- Comment #4 from David Smith <dsmith at redhat dot com> 2011-03-03 18:26:32 UTC ---
(In reply to comment #3)
> Created attachment 5243 [details]
> Fix with %{ symbols %}.
> 
> (In reply to comment #2)
> > we don't handle unknown option values like this anywhere else (that I know
> > of).  If we decide this is a good idea, we should probably file a bug against
> > the rest of the option decoding functions.
> 
> Yes, that should be done.
> 
> > into something like this (actually using the #defines):
> >   if (f & %{ WNOHANG %})
> 
> Attached.

Your latest attachment looks good to me, doesn't have any compile problems on
x86_64 RHEL4, so go ahead and check it in.

--

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
jan.kratochvil at redhat dot com | 3 Mar 2011 19:41
Favicon

[Bug tapsets/12470] Fix _wait4_opt_str

http://sourceware.org/bugzilla/show_bug.cgi?id=12470

Jan Kratochvil <jan.kratochvil at redhat dot com> changed:

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

--- Comment #5 from Jan Kratochvil <jan.kratochvil at redhat dot com> 2011-03-03 18:41:34 UTC ---
Thanks for the review.

commit 97da377b94e86c5576ea34d2ee59e7f30addc1ae
Author: Jan Kratochvil <jan.kratochvil <at> redhat.com>
Date:   Thu Mar 3 19:38:21 2011 +0100

    Fix _wait4_opt_str output.
    http://sourceware.org/bugzilla/show_bug.cgi?id=12470

        * tapset/aux_syscalls.stp (_internal_wait_opt_str): New.
        (_wait4_opt_str, _waitid_opt_str): Call it.
        * tapset/nd_syscalls2.stp (nd_syscall.wait4) <options>
        (nd_syscall.waitpid) <options, options_str>: Cut it to 32-bit.
        * tapset/syscalls2.stp: Likewise.

--

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
(Continue reading)

Permalink | Reply | 0 comments |
headers
dsmith at redhat dot com | 3 Mar 2011 20:09
Favicon

[Bug tapsets/12471] Support wait4 *status printing

http://sourceware.org/bugzilla/show_bug.cgi?id=12471

--- Comment #6 from David Smith <dsmith at redhat dot com> 2011-03-03 19:09:14 UTC ---
(In reply to comment #5)
> Done this way, the code looks much better now.

The code does look much better now.  A few final small notes:

- Could you add the new 'status_str' support to the 'nd_syscall.wait4.return'
probe (in tapset/nd_syscalls2.stp)?

- Could you print out the new 'status_str' variable in
testsuite/buildok/syscalls2-detailed.stp ('syscall.wait4.return' probe) and in
testsuite/buildok/nd_syscalls2-detailed.stp ('nd_syscall.wait4.return' probe)?

--

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
dsmith at redhat dot com | 3 Mar 2011 23:43
Favicon

[Bug uprobes/12540] New: "Could not obtain information on password file" build error

http://sourceware.org/bugzilla/show_bug.cgi?id=12540

           Summary: "Could not obtain information on password file" build
                    error
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: uprobes
        AssignedTo: systemtap <at> sources.redhat.com
        ReportedBy: dsmith <at> redhat.com

On a 2.6.32.12-115.fc12.ppc64 system, I configured/build like so:

# ../src/configure --prefix=/notnfs/dsmith/stap/install --disable-docs
--disable-server
# make && sudo make install

When I got to build uprobes, I get the following error:

# sudo make -C /notnfs/dsmith/stap/install/share/systemtap/runtime/uprobes
make: Entering directory
`/notnfs/dsmith/stap/install/share/systemtap/runtime/uprobes'
make -C /lib/modules/2.6.32.12-115.fc12.ppc64/build
SUBDIRS=/notnfs/dsmith/stap/install/share/systemtap/runtime/uprobes modules
make[1]: Entering directory `/usr/src/kernels/2.6.32.12-115.fc12.ppc64'
  CC [M]  /notnfs/dsmith/stap/install/share/systemtap/runtime/uprobes/uprobes.o
  Building modules, stage 2.
  MODPOST 1 modules
(Continue reading)

Permalink | Reply | 0 comments |

Gmane