This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC] Probes don't hit in an already running process
- From: Torsten Polle <Torsten dot Polle at gmx dot de>
- To: David Smith <dsmith at redhat dot com>
- Cc: systemtap at sourceware dot org
- Date: Sat, 16 Aug 2014 22:51:34 +0200
- Subject: Re: [RFC] Probes don't hit in an already running process
- Authentication-results: sourceware.org; auth=none
- References: <m2zjl1y78q dot fsf at gmx dot de>, <5321B6A7 dot 2050908 at redhat dot com> <trinity-ace1755b-5a27-463a-81a0-9ec45f0a4c9c-1394864987187 at 3capp-gmx-bs43>
David,
Am 15.03.2014 um 07:29 schrieb Torsten Polle <Torsten.Polle@gmx.de>:
> David
>
> > Gesendet: Donnerstag, 13. März 2014 um 14:46 Uhr
> > Von: "David Smith" <dsmith@redhat.com>
> > An: "Torsten Polle" <Torsten.Polle@gmx.de>, systemtap@sourceware.org
> > Betreff: Re: [RFC] Probes don't hit in an already running process
> > On 03/07/2014 04:27 PM, Torsten Polle wrote:
> > > Hi,
> > >
> > > I've made the observation that probes sometimes don't hit when I
> > > start staprun after the process (where the probes should hit)
> > > started. After some tests, I found out that only multi-thread
> > > processes were affected under a certain condition.
> > >
> > > The patch below fixes the issue for me. But I've no clue about
> > > possible side effects. In my first attempt to fix the issue, I
> > > also included the calls to __stp_call_callbacks() into the
> > > guarded area. My probes hit, but calls to usymname(uaddr()) in
> > > the probe body only printed the address instead of the symbol of
> > > the probed function.
> > >
> > > Any advice of how I can improve the patch is appreciated.
> >
> > Hmm. we've had this problem before, and I thought we fixed it. See
> > PR12642 (utrace: taskfinder misses events when main thread does not
> > go through at least one quiesce):
> >
> > <https://sourceware.org/bugzilla/show_bug.cgi?id=12642>
>
> Thanks for the hint. I checked the program that is attached to the bug
> report. The program does not differ from my test program.
>
> I'll check why UTRACE_INTERRUPT does lead to the task work to be run
> for sleeping main threads in my setup.
it took me some time to check this issue in July and again some more time to write this mail.
Finally, I found out that UTRACE_INTERUPT was not handled properly in utrace_resume. Before I wanted to get back to you, I double checked with the newest version only to find out that you had already fixed the problem with "Fixed PR17181 by making utrace handle interrupting processes better."
> > One of the things the commit that fixes that bug does is add a test
> > case, called 'main_quiesce.exp'. Does that pass or fail for you
> > (run "make installcheck RUNTESTFLAGS=main_quiesce.exp")? If it
> > passes, we need to figure out what is different about your
> > multi-thread process that still causes this to happen.
> >
> > --
> > David Smith
> > dsmith@redhat.com
> > Red Hat
> > http://www.redhat.com
> > 256.217.0141 (direct)
> > 256.837.0057 (fax)
>
> Kind Regards,
> Torsten
Kind Regards,
Torsten