headers
amouehsan | 2 Aug 2011 00:15
Picon

Re: full dwarf backtracing kernel to user


Hi, 
I am trying systemtap and when probing a kernel function ("bio_endio") I
need to get the user backtrace. When I use 
probe kernel.function("bio_endio <at> fs/bio.c:1443").call 
{
   print_ubacktrace();
}
I get the following message. 
<no ubacktrace: kernel.function("bio_endio <at> fs/bio.c:1443").call>

I tried using --ldd but it didn't help. By what you have written:

Mark Wielaard-4 wrote:
> 
> I have been cleaning up the dwarf unwinder a bit, and after some small
> fixes (all in git trunk now) it is now finally possible to unwind fully
> from kernel space right into user space. This provides better user
> backtraces when a probe point triggered in kernel space. 
> 
>  With the new setup it is now possible to get a 
> full user space register set to start the user space dwarf unwinder and
> always do a full unwind. One example is setting a probe point on
> syscall.close and then doing a print_ubacktrace().
> 
I understand the feature I wanted to use was not implemented before. Is my
understanding right? If no, how can I do that? If yes, how I can have this
new feature enabled? Should I get a new code and re-compile systemtap?

Thanks,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Wielaard | 2 Aug 2011 10:24
Picon
Favicon

Re: full dwarf backtracing kernel to user

On Mon, 2011-08-01 at 15:15 -0700, amouehsan wrote:
> I am trying systemtap and when probing a kernel function ("bio_endio") I
> need to get the user backtrace. When I use 
> probe kernel.function("bio_endio <at> fs/bio.c:1443").call 
> {
>    print_ubacktrace();
> }
> I get the following message. 
> <no ubacktrace: kernel.function("bio_endio <at> fs/bio.c:1443").call>
> 
> I tried using --ldd but it didn't help.

It might be that stap is already totally correct. It can be that your
probe point triggered totally in a kernel context, without any user
space trigger. You can check by doing:

stap -e 'probe kernel.function("bio_endio <at> fs/bio.c:1443").call
{ printf("%d %s\n", pid(), execname()); print_ubacktrace(); }'

For example for me this gives output like:

0 swapper
<no ubacktrace: kernel.function("bio_endio <at> fs/bio.c:1442").call>
3373 firefox-bin
 0x7faa1e35a670

So, the first does indeed not have any user backtrace associated with
it. The second does have one, but since I didn't provide -d firefox-bin
--ldd stap couldn't unwinding past the initial user space address.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Wielaard | 3 Aug 2011 13:36
Picon
Favicon

Individual Probe States

Hi,

We have grown a lot of different probe handlers over the years. While
working on the user/kernel backtrace stuff it has been a little
confusing at times what state is really available depending on which
probe handler fired. A couple of probe handlers have context fields in
which they put specific data associated with the handler. So checking
some of these fields could tell us a bit more about the actual context
available (user/kernel context, registers, u/kretprobe handlers, etc.)

What I have done is tried to document all the (low-level) handlers we
have, make explicit in the CONTEXT which one is currently "life", and
moved all individual probe state into one union (to safe space and make
it easier to just clear it all on entry). [In some earlier commits I
also cleaned up and shrunk the context a little, but I think those
cleanups weren't controversial.]

This will make things a little easier for the backtrace code, since it
has a more explicit view of the current probe context. Hopefully it is
not completely insane and also useful to other runtime code. If this
totally destroys the runtime context code please yell and scream. Also
please look over the descriptions/comments I added for the various
handlers. Maybe I misunderstood some. And maybe some more context could
be moved into the "ips". Originally I thought the "type" should be part
of the probe instead of passing it to common_probe_entryfn_prologue ()
as string. But I got a little confused about where in the hierarchy it
should go (probe, probe_point, derived_probe). So any
clarification/cleanup of that part would be helpful too.

The various probe handlers that we now distinguish:
(Continue reading)

Permalink | Reply | 0 comments |
headers
mjw at redhat dot com | 4 Aug 2011 21:22
Favicon

[Bug runtime/13055] New: Replace kern_path_parent in runtime/procfs.c

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

           Summary: Replace kern_path_parent in runtime/procfs.c
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
        AssignedTo: systemtap <at> sourceware.org
        ReportedBy: mjw <at> redhat.com

runtime/procfs.c uses kern_path_parent(), but that is no longer exported
since:

commit e3c3d9c838d48c0341c40ea45ee087e3d8c8ea39
Author: Al Viro <viro <at> zeniv.linux.org.uk>
Date:   Mon Jun 27 17:14:56 2011 -0400

    unexport kern_path_parent()

    Signed-off-by: Al Viro <viro <at> zeniv.linux.org.uk>

Maybe we can use one of the new (exported) functions introduced in:

commit dae6ad8f37529963ae7df52baaccf056b38f210e
Author: Al Viro <viro <at> zeniv.linux.org.uk>
Date:   Sun Jun 26 11:50:15 2011 -0400

    new helpers: kern_path_create/user_path_create
(Continue reading)

Permalink | Reply | 1 comment |
headers
Frank Ch. Eigler | 4 Aug 2011 23:23
Picon
Favicon
Gravatar

testing on amazon ec2 ami linux

Hi -

Out of curiosity, and preparing for a networked systemtap
demonstration, I tried out Amazon's AWS EC2 service.  They small
virtual machines for nearly-free and big ones for more $$.  I tried
out just the freebie ones[1] for now, and these run Amazon AMI Linux,
a custom linux distribution similar to RHEL-6, but with a newer
kernel.

I tried out the 2011.02.1 beta.  It turns out this distro is
well-stocked with everything a systemtap cloud experimenter may want:
yum access to development tools, debuginfo repositories, utrace in the
kernel, and a build of systemtap-1.4 itself.

Except for one bug[2], everything just works & fast, even perhaps fun.

- FChE

[1] http://aws.amazon.com/free/
[2] The kernel-debuginfo packages have a build bug resulting in
accidentally stripping the vmlinux file, so kernel.function probes
don't work, but this is being fixed as we speak.
Permalink | Reply | 0 comments |
headers
fche | 6 Aug 2011 16:27
Favicon

new systemtap snapshot available

A new automated systemtap source snapshot is available
ftp://sources.redhat.com/pub/systemtap/snapshots/systemtap-20110806.tar.bz2
1744773 bytes, 4310926 tag
See also ftp://sources.redhat.com/pub/systemtap/snapshots/
Permalink | Reply | 0 comments |
headers
William Cohen | 8 Aug 2011 21:52
Picon
Favicon

SystemTap LiveCD (LiveDVD?) creation for F-15

Hi All,

It was brought to my attention that the systemtap live cd images were rather old (for Fedora 12). Today I
generated a Fedora-15 version of the sytemtap live cd with the following command:

livecd-creator --config=fedora-livecd-stap.ks --fslabel=Fedora-15-x86_64-SystemTap-Live

The x86_64 iso and kickstart files are at ftp://sourceware.redhat.com/pub/systemtap/livecds/

Please give this a try and let me know whether there are any problems with this.

-Will
Permalink | Reply | 0 comments |
headers
Chris Meek | 9 Aug 2011 20:16
Picon
Favicon

Using abrt to automatically download and install debuginfo

Hi all,

I recently added a feature (PR12773, commit 
e1e8b44e3293090f29262beb1b0762951b833e62)
to SystemTap that uses abrt to automatically download and install needed 
debuginfo. I will be
extending the functionality in the near future to include command line 
options to control the
use of the feature (such as whether or not to use it, or to set a 
timeout interval).

In my tests, I found that a small debuginfo file of around 0.2MB took 
only an average of
1.34 seconds to download and install, whereas a larger file of 76.5 MB 
took around 6.4
minutes to download and install. Of course these times are heavily 
dependant on the
internet connection, so they should only be taken as a rough ballpark 
estimate.

Example:

$ stap -e 'probe process("/bin/gzip").function("*") { log(pp()) }'

If the gzip debuginfo is not already installed, SystemTap will call
"abrt-action-install-debuginfo-to-abrt-cache" to first download and then 
install the "gzip.debug"
file into: "/var/cache/abrt-di/usr/lib/debug/" . SystemTap will then 
look in this directory to use the
debuginfo for the probe.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Chris Meek | 9 Aug 2011 22:31
Picon
Favicon

Re: Fwd: Using abrt to automatically download and install debuginfo

On 08/09/2011 04:08 PM, Bill Nottingham wrote:
> Tim Burke (tburke <at> redhat.com) said:
>> In my tests, I found that a small debuginfo file of around 0.2MB took
>> only an average of
>> 1.34 seconds to download and install, whereas a larger file of 76.5 MB
>> took around 6.4
>> minutes to download and install. Of course these times are heavily
>> dependant on the
>> internet connection, so they should only be taken as a rough ballpark
>> estimate.
>>
>> Example:
>>
>> $ stap -e 'probe process("/bin/gzip").function("*") { log(pp()) }'
>>
>> If the gzip debuginfo is not already installed, SystemTap will call
>> "abrt-action-install-debuginfo-to-abrt-cache" to first download and then
>> install the "gzip.debug"
>> file into: "/var/cache/abrt-di/usr/lib/debug/" . SystemTap will then
>> look in this directory to use the
>> debuginfo for the probe.
>>
>> If you have any comments or suggestions, I'd like to hear them.
> Is it possible to use abrt's retrace server to not require the debuginfo
> locally?
>
> Bill
Hi Bill,

It appears that the retrace server does not actually server the debuginfo
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Meek | 9 Aug 2011 22:32
Picon
Favicon

Re: Using abrt to automatically download and install debuginfo

On 08/09/2011 02:16 PM, Chris Meek wrote:
> Hi all,
>
> I recently added a feature (PR12773, commit 
> e1e8b44e3293090f29262beb1b0762951b833e62)
> to SystemTap that uses abrt to automatically download and install 
> needed debuginfo. I will be
> extending the functionality in the near future to include command line 
> options to control the
> use of the feature (such as whether or not to use it, or to set a 
> timeout interval).
>
> In my tests, I found that a small debuginfo file of around 0.2MB took 
> only an average of
> 1.34 seconds to download and install, whereas a larger file of 76.5 MB 
> took around 6.4
> minutes to download and install. Of course these times are heavily 
> dependant on the
> internet connection, so they should only be taken as a rough ballpark 
> estimate.
>
> Example:
>
> $ stap -e 'probe process("/bin/gzip").function("*") { log(pp()) }'
>
> If the gzip debuginfo is not already installed, SystemTap will call
> "abrt-action-install-debuginfo-to-abrt-cache" to first download and 
> then install the "gzip.debug"
> file into: "/var/cache/abrt-di/usr/lib/debug/" . SystemTap will then 
> look in this directory to use the
(Continue reading)

Permalink | Reply | 1 comment |

Gmane