This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Queries on SystemTap - with focus on User Space debugging
- From: Manjusha Ajay <manjusha dot ajay at gmail dot com>
- To: fche at redhat dot com
- Cc: systemtap at sourceware dot org, adrien at kunysz dot be
- Date: Thu, 26 May 2011 15:24:54 +0530
- Subject: Re: Queries on SystemTap - with focus on User Space debugging
- References: <4ddc870c.c9cae30a.71aa.04da@mx.google.com> <OFC45DE291.D6E993B3-ON6525789C.00234213-6525789C.00324BA5@ibsplc.com>
Hi Frank,
I tried adding the probe kernel.function("send_sig") in my code to
trace my test program, but it so happened that this particular probe
was not hit during the execution of the process. Not sure why that
happened.
probe kernel.function("send_sig") {
? ? ?if ($sig == 11 && p && task_pid(p) == target()) {
? ? ? print_ubacktrace()
? ? ?}
}
Also got a warning when I ran the above script
> stap -c "./test_segfault' test.stp
WARNING: ?read-only local variable 'p' ?: identifier 'p' at test.stp:19:20
? ?source: ? ? ? ? ? ? if ($sig == 11 && p && task_pid(p) == target()) {
% stap -L 'kernel.function("send_sig")' ? gave me the following result
kernel.function("send_sig@kernel/signal.c:1169")
Iam using RHEL 5.4, ?kernel release 2.6.18-164.el5
I had also tried adding probe kernel.function("send_signal") which was
hit, but then print_ubacktrace gave me the kernel stack trace whereas
i was expecting the stack trace of the user space application.
I got the above mentioned warning even in this case.
Manjusha.
-----Original Message-----
From: Frank Ch. Eigler
Sent: ?24/05/2011 18:34:38
Subject: ?Re: Queries on SystemTap - with focus on User Space debugging
manjusha.ajay wrote:
> [...]
> probe process("test_segfault").syscall
> ?{
> ?pid = pid()
> ?if (pid == target())
> ?{
> ? ? ?if ($syscall == 11)
Syscall #11 may be execve or munmap; neither appears to have much to
do with SIGSEGV (which is signal #11). ?We do not have a convenient
probe point in the tapset to commemorate signal delivery, but the
following ought to do:
% stap -L 'kernel.function("send_sig")'
kernel.function("send_sig@kernel/signal.c:1300") $sig:int $p:struct
task_struct* $priv:int
i.e.,
probe kernel.function("send_sig") {
? ? ?if ($sig == 11 && p && task_pid(p) == target()) {
? ? ? ? ....
? ? ?}
}
> ? ? ?{
> ? ? ?// Trying to stop the process to collect the
> ? ? ?// required data when it receives SIGSEGV
> ? ? ?stop_cmd = sprintf("kill -s STOP %d", pid)
> ? ? ?system(stop_cmd)
>
> ? ? ?print_ubacktrace()
>
> ? ? ?// Resume the process
> ? ? ?cont_cmd = sprintf ("kill -s CONT %d", pid)
> ? ? ?system(cont_cmd)
> ? ? }
> ? ? }
> ?}
This is more than necessary. ?You neither need to kill -STOP or -CONT
around a print_ubacktrace(). ?Just print_ubacktrace(). ?The other
problem is that the system() tapset function does not run the given
command string immediately. ?It enqueues it for execution *soon*.
This should explain why in your tests some of the kill jobs showed an
error with a missing process: it was gone by the time the enqueued
jobs got started.
- FChE