public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mjw@redhat.com>
To: Gaurav Dhiman <dimanuec@gmail.com>
Cc: "Frank Ch. Eigler" <fche@redhat.com>, systemtap@sourceware.org
Subject: Re: Segmentation Fault: Task died at uprobe probepoint
Date: Tue, 15 Jun 2010 18:07:00 -0000	[thread overview]
Message-ID: <1276593837.4364.19.camel@springer.wildebeest.org> (raw)
In-Reply-To: <AANLkTim0fH6McnBGgIJ_2qyZyrNKtosmr-z34oQVoWjD@mail.gmail.com>

On Mon, 2010-06-14 at 20:52 -0700, Gaurav Dhiman wrote:
> On Mon, Jun 14, 2010 at 6:33 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
> > Gaurav Dhiman <dimanuec@gmail.com> writes:
> >> [...]
> >> Following are the logs from the Pass 5 of the run with stap -vvvt
> >> -DDEBUG_UPROBES:
> >>
> >> Pass 5: starting run.
> >> [...]
> >> stapio:stp_main_loop:571 probe_start() returned 0
> >> stap_uprobe_change_plus:67: +uprobe spec 0 idx 0 process uprobe-test[25763] addr 0000000000400517 pp process("/home/gdhiman/tests/uprobe-test").function("test_func@/home/gdhiman/tests/uprobe-test.c:4")
> >> test begin!!
> >> test_func called!
> >> i=0x5
> >> stap_uprobe_change_minus:220: -uprobe spec 0 idx 0 process uprobe-test[25763] reloc 0000000000400517 pp process("/home/gdhiman/tests/uprobe-test").function("test_func@/home/gdhiman/tests/uprobe-test.c:4")
> >>
> >> The program receives a SIGSEGV signal at this point.
> >
> > OK, something is wrong here.  See that -uprobe line?  It means stap
> > has for some reason determined that it's time to remove the uprobe,
> > but that should not happen until either the script or the target
> > program exits.
> >
> > This will make things more verbose, but could you try adding
> > -DDEBUG_TASK_FINDER and -DDEBUG_TASK_FINDER_VMA to the stap
> > command line?
> >
> You are right, that looks suspicious; it is actually removing the
> probe, when it should not be doing it. Here is the more verbose
> output:
> 
> test_func called!
> i=0x5
> stap_uprobe_process_found:246: -proc pid 27237 stf ffffffffa001dce0
> ffffffffa001dce0 path /home/gdhiman/tests/uprobe-test
> stap_uprobe_change_minus:220: -uprobe spec 0 idx 0 process
> uprobe-test[27237] reloc 0000000000400517 pp
> process("/home/gdhiman/tests/uprobe-test").function("test_func@/home/gdhiman/tests/uprobe-test.c:4")
> _stp_tf_exec_cb:29: tsk 27237:27237 , register_p: 0, process_p: 1

Unless I am reading the logs wrong, I do think this is expected. The
process gets a SIGSEGV and so uprobes is notified that it needs to clean
up (-proc pid 27237 means process is gone).

> > I meant the uprobe-test binary, just to see what instructions were
> > in the vicinity of the test_func function.  Just that area.
> >
> 
> Here it is:
> 
> 000000000040050c <test_func>:
>   40050c:       55                      push   %rbp
>   40050d:       48 89 e5                mov    %rsp,%rbp
>   400510:       48 83 ec 10             sub    $0x10,%rsp
>   400514:       89 7d fc                mov    %edi,-0x4(%rbp)
>   400517:       8b 75 fc                mov    -0x4(%rbp),%esi
>   40051a:       bf 3c 06 40 00          mov    $0x40063c,%edi
>   40051f:       b8 00 00 00 00          mov    $0x0,%eax
>   400524:       e8 cf fe ff ff          callq  4003f8 <printf@plt>
>   400529:       8b 45 fc                mov    -0x4(%rbp),%eax
>   40052c:       c9                      leaveq
>   40052d:       c3                      retq

That does look OK, even though it looks different from my local build:

Dump of assembler code for function test_func:
   0x080483d0 <+0>:	push   %ebp
   0x080483d1 <+1>:	mov    %esp,%ebp
   0x080483d3 <+3>:	push   %ebx
   0x080483d4 <+4>:	sub    $0x14,%esp
   0x080483d7 <+7>:	mov    0x8(%ebp),%ebx
   0x080483da <+10>:	movl   $0x80484f4,(%esp)
   0x080483e1 <+17>:	mov    %ebx,0x4(%esp)
   0x080483e5 <+21>:	call   0x80482f4 <printf@plt>
   0x080483ea <+26>:	mov    %ebx,%eax
   0x080483ec <+28>:	add    $0x14,%esp
   0x080483ef <+31>:	pop    %ebx
   0x080483f0 <+32>:	pop    %ebp
   0x080483f1 <+33>:	ret    
End of assembler dump.

What compiler and flags did you use? Here gcc version 4.4.4 20100503
(Red Hat 4.4.4-2) with -g -O2.

If possible could you set ulimit -c unlimited and catch the core file of
the program and give the disassembly from test_func in the core? Maybe
the breakpoint instruction in there was misplaced?

Thanks,

Mark 

  reply	other threads:[~2010-06-15  9:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-14  9:18 Gaurav Dhiman
2010-06-14 12:55 ` Srikar Dronamraju
     [not found]   ` <AANLkTilvvj9hdiaa9VWjO0j-jK02LMweg5cAEBgoLyRK@mail.gmail.com>
2010-06-15  9:11     ` Gaurav Dhiman
2010-06-15 17:46       ` Mark Wielaard
2010-06-16 13:54         ` Gaurav Dhiman
2010-06-16 19:05           ` Frank Ch. Eigler
2010-06-22  8:57             ` Gaurav Dhiman
2010-06-22 10:36               ` Roland McGrath
2010-06-22 13:05                 ` Gaurav Dhiman
2010-06-22 13:11                   ` Roland McGrath
2010-06-22 13:12                     ` Gaurav Dhiman
2010-06-15 18:17     ` Srikar Dronamraju
2010-06-16 14:19       ` Gaurav Dhiman
2010-06-14 21:06 ` Frank Ch. Eigler
2010-06-15  9:24   ` Gaurav Dhiman
2010-06-15 10:39     ` Frank Ch. Eigler
2010-06-15 12:25       ` Gaurav Dhiman
2010-06-15 18:07         ` Mark Wielaard [this message]
2010-06-16 14:08           ` Gaurav Dhiman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1276593837.4364.19.camel@springer.wildebeest.org \
    --to=mjw@redhat.com \
    --cc=dimanuec@gmail.com \
    --cc=fche@redhat.com \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).