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: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Manjusha Ajay <manjusha dot ajay at gmail dot com>
- Cc: systemtap at sourceware dot org, adrien at kunysz dot be
- Date: Thu, 26 May 2011 06:23:54 -0400
- 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> <BANLkTi=wWUbJkE0gVV+PqQnrCcFP3UTsBA@mail.gmail.com>
Hi -
On Thu, May 26, 2011 at 03:24:54PM +0530, Manjusha Ajay wrote:
> [...]
> 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
Ah yes, an appropriate warning: I meant $p instead of p above,
since we're trying to extract the p parameter from the context
of the send_sig function call.
It appears difficult to place an architecture-neutral kernel probe at
the point where a page fault is about to be declared a SIGSEGV type
error. Might try kernel.function("force_sig_info") instead,
filtering on $sig==11.
> I had also tried adding probe kernel.function("send_signal") which was
> hit, but then print_ubacktrace gave me the kernel stack trace [...]
I can't explain that, except something fuzzy perhaps: by then, the
process context has been munged enough that user-space unwinding can't
find its starting points.
- FChE