headers
fche | 1 Nov 2008 15:27
Favicon

new systemtap snapshot available

A new automated systemtap source snapshot is available
ftp://sources.redhat.com/pub/systemtap/snapshots/systemtap-20081101.tar.bz2
1014758 bytes, 6a1d90ee1b3471847ff11e74bc2cb19928f5de1a tag
See also ftp://sources.redhat.com/pub/systemtap/snapshots/
Permalink | Reply | 0 comments |
headers
Dongtao Liu | 1 Nov 2008 21:13
Picon

Re: Does anyone have idea of how to trace the funtion "gethostbyname"?

yes, it is the function in libc. I downloaded the source code of
glibc-2.7.3 and found gethostbyname() function in
/resolv/gethnamaddr.c

dliu <at> dliu-desktop:/usr/src/glibc/glibc-2.7/resolv$ ls
arpa          gai_misc.c      getaddrinfo_a.c  inet_net_pton.c
netdb.h      ns_samedomain.c  res_debug.c  res_mkquery.c  tst-aton.c
Banner        gai_misc.h      gethnamaddr.c    inet_ntop.c
nsap_addr.c  nss_dns          res_debug.h  resolv.h
tst-inet_ntop.c
base64.c      gai_notify.c    herror.c         inet_pton.c
ns_name.c    ns_ttl.c         res_hconf.c  res_query.c    tst-leaks2.c
Depend        gai_sigqueue.c  inet_addr.c      Makefile
ns_netint.c  README           res_hconf.h  res_send.c     tst-leaks.c
gai_cancel.c  gai_suspend.c   inet_neta.c      mapv4v6addr.h
ns_parse.c   res_comp.c       res_init.c   res-state.c    Versions
gai_error.c   ga_test.c       inet_net_ntop.c  mapv4v6hostent.h
ns_print.c   res_data.c       res_libc.c   sys

2008/10/31 Breno Leitao <leitao <at> linux.vnet.ibm.com>:
> Dongtao Liu wrote:
>> I recently doing some work to record all DNS lookups in the system.
>> Could anyone tell me how to trace the function of gethostbyname using
>> SystemTap?
> Since this is not a kernel function, you might want to probe userspace
> functions.
>
Permalink | Reply | 0 comments |
headers
Dongtao Liu | 1 Nov 2008 21:14
Picon

Re: Does anyone have idea of how to trace the funtion "gethostbyname"?

Is it "/lib/libc-2.7.so" in my system?
probe process("/lib/libc-2.7.so").function("gethostbyname").call {
log(user_string($name)) }

Then how long will SystemTap support to trace this function? Thans a lot!

This is the information about libc in my system.

dliu <at> dliu-desktop:/lib$ ls -all libc.so.6
lrwxrwxrwx 1 root root 11 2008-10-23 22:02 libc.so.6 -> libc-2.7.so
dliu <at> dliu-desktop:/lib$ ls -all libc-2.7.so
-rwxr-xr-x 1 root root 1274092 2008-09-12 10:32 libc-2.7.so

dliu <at> dliu-desktop:/lib$ ls -all libc*.so*
-rwxr-xr-x 1 root root 1274092 2008-09-12 10:32 libc-2.7.so
lrwxrwxrwx 1 root root      11 2008-10-23 22:02 libcap.so -> libcap.so.1
lrwxrwxrwx 1 root root      14 2008-10-23 17:30 libcap.so.1 -> libcap.so.1.10
-rw-r--r-- 1 root root   10316 2007-07-31 15:20 libcap.so.1.10
lrwxrwxrwx 1 root root      17 2008-10-23 17:30 libcfont.so.0 ->
libcfont.so.0.0.0
-rw-r--r-- 1 root root   11512 2008-02-06 17:49 libcfont.so.0.0.0
-rw-r--r-- 1 root root  181724 2008-09-12 10:32 libcidn-2.7.so
lrwxrwxrwx 1 root root      14 2008-10-23 22:02 libcidn.so.1 -> libcidn-2.7.so
lrwxrwxrwx 1 root root      17 2008-10-23 17:30 libcom_err.so.2 ->
libcom_err.so.2.1
-rw-r--r-- 1 root root    7444 2008-03-27 13:25 libcom_err.so.2.1
lrwxrwxrwx 1 root root      19 2008-10-23 17:30 libconsole.so.0 ->
libconsole.so.0.0.0
-rw-r--r-- 1 root root   73312 2008-02-06 17:49 libconsole.so.0.0.0
-rw-r--r-- 1 root root   38300 2008-09-12 10:32 libcrypt-2.7.so
(Continue reading)

Permalink | Reply | 0 comments |
headers
mjw at redhat dot com | 2 Nov 2008 18:03
Favicon

[Bug tapsets/5434] Error processing (missing) nfsservctl syscall


------- Additional Comments From mjw at redhat dot com  2008-11-02 17:03 -------
Got another report about this.
The problem comes from this part in fs/compat.c:
#if defined(CONFIG_NFSD) || defined(CONFIG_NFSD_MODULE)
[...]
asmlinkage long compat_sys_nfsservctl(int cmd,
                                struct compat_nfsctl_arg __user *arg,
                                union compat_nfsctl_res __user *res)
{
[...]
}
#else /* !NFSD */
long asmlinkage compat_sys_nfsservctl(int cmd, void *notused, void *notused2)
{
        return sys_ni_syscall();
}
#endif

So compat_sys_nfsservctl() has differently named arguments depending on whether
or not NFSD is configured in. I also don't know a nice solution for this. But it
breaks simple things like:
stap -e 'probe syscall.* {printf("%s(%s)\n", probefunc(), argstr)}' -c 'echo'

semantic error: unable to find local 'arg' near pc 0xffffffff802cce2f
(alternatives: cmd notused notused2): identifier '$arg' at
/usr/local/share/systemtap/tapset/syscalls2.stp:66:56
        source:         argstr = sprintf("%s, %p, %p", _nfsctl_cmd_str($cmd),
$arg, $res)
(Continue reading)

Permalink | Reply | 0 comments |
headers
mjw at redhat dot com | 3 Nov 2008 09:52
Favicon

[Bug runtime/6964] process probes cause kernel crash on f9


------- Additional Comments From mjw at redhat dot com  2008-11-03 08:52 -------
This workaround is causing some confusion for people (me included) who use
systemtap git trunk since -c doesn't work reliably now. Is there a timeline to
get this fixed for real?

--

-- 

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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
mjw at redhat dot com | 3 Nov 2008 11:30
Favicon

[Bug translator/5890] sys.stp andtestsuite/systemtap.syscall/sys.stp fail on 2.6.25 x86_64


------- Additional Comments From mjw at redhat dot com  2008-11-03 10:30 -------
Same issue for trying to access $return in compat_sys_recvmsg:

$ /usr/local/systemtap/bin/stap -v -e 'probe syscall.*.return { printf("%s =>
%d\n", probefunc(), $return)}'
Pass 1: parsed user script and 46 library script(s) in 230usr/10sys/252real ms.
semantic error: unable to find return value near pc 0xffffffff8122a292 for
compat_sys_recvmsg(net/compat.c): identifier '$return' at <input>:1:60
        source: probe syscall.*.return { printf("%s => %d\n", probefunc(), $return)}
                                                                           ^
Pass 2: analyzed script: 395 probe(s), 394 function(s), 14 embed(s), 0 global(s)
in 3090usr/480sys/3596real ms.
Pass 2: analysis failed.  Try again with more '-v' (verbose) options.

--

-- 

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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
Mark Wielaard | 3 Nov 2008 12:03
Picon
Favicon

Re: Systemtap generator for simple timings collection

Hi Fabio,

On Fri, 2008-10-24 at 15:51 -0200, Fabio Olive Leite wrote:
> While working on a set of systemtaps to help us assess NFS performing
> regressions between RHEL releases (quite an obsession), I have abstracted
> my set of taps to the point where I actually made an AWK script that
> reads a list of kernel functions and generates a systemtap script that
> collects timings on those functions, outputing statistics on those timings
> when interrupted. I thought I would post it here as it became a generally
> interesting tool.

Nice! I added a reference to this on the systemtap wiki under "Systemtap
Applications": http://sourceware.org/systemtap/wiki/HomePage

Thanks,

Mark
Permalink | Reply | 0 comments |
headers
Mark Wielaard | 3 Nov 2008 12:13
Picon
Favicon

Re: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-0.7-433-g8576ea4

Hi Wenji,

On Mon, 2008-11-03 at 08:40 +0000, wenji <at> sourceware.org wrote:
> commit 8576ea4be5619d9c169cab385ac0d31174fdee41
> Author: Wenji Huang <wenji.huang <at> oracle.com>
> Date:   Mon Nov 3 01:58:48 2008 -0500
> 
>     Fix hung test due to workaround for PR6964.

I must say I don't really like this workaround in the testsuite for
another workaround. The test correctly points out that because of the
previous workaround -c doesn't work reliably anymore. IMHO we shouldn't
have this cascading pile of workarounds, especially not in the tests.
Please do make sure to also revert this one, when the original PR6964
workaround is reverted.

Thanks,

Mark
Permalink | Reply | 1 comment |
headers
Mark Wielaard | 3 Nov 2008 12:50
Picon
Favicon

Re: socket-trace.stp: no match while resolving probe point kernel.function("* <at> net/socket.c")

On Wed, 2008-10-29 at 21:41 -0400, Dongtao Liu wrote:
> Thank you for reply. I found it pretty strange that if I do not use
> "* <at> net/socket.c" but use function in socket.c directly such as
> sock_create. SystemTap can work well and trace all the calls of
> fuction sock_create. I don't know why...

That is indeed strange. So this works for you:
$ stap -e 'probe kernel.function("sock_sendmsg"){log(pp())}'
But this doesn't:
$ stap -e 'probe kernel.function("sock_sendmsg <at> net/socket.c"){log(pp())}'

Does the output (pp()) of the running version, or if you run it with
-vv, give any hints about the why?

Cheers,

Mark
Permalink | Reply | 1 comment |
headers
Wenji Huang | 4 Nov 2008 02:23
Picon
Favicon

Re: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-0.7-433-g8576ea4

Mark Wielaard wrote:
> Hi Wenji,
> 
> On Mon, 2008-11-03 at 08:40 +0000, wenji <at> sourceware.org wrote:
>> commit 8576ea4be5619d9c169cab385ac0d31174fdee41
>> Author: Wenji Huang <wenji.huang <at> oracle.com>
>> Date:   Mon Nov 3 01:58:48 2008 -0500
>>
>>     Fix hung test due to workaround for PR6964.
> 
> I must say I don't really like this workaround in the testsuite for
> another workaround. The test correctly points out that because of the
> previous workaround -c doesn't work reliably anymore. IMHO we shouldn't
> have this cascading pile of workarounds, especially not in the tests.
> Please do make sure to also revert this one, when the original PR6964
> workaround is reverted.
> 
> Thanks,
> 
> Mark
> 
Hi Mark,

I admit that current workaround is a little annoying. But we need to 
wait utrace update. In fact, "stap -c" will cause kernel panic even on 
2.6.27+latest utrace. One simplest way is to change BUG_ON to WARN_ON so 
that no kernel panic come up any more. I think the commit will be 
reverted once new utrace kernel is ready.

Regards,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane