This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Aw: 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, 15 Mar 2014 07:29:47 +0100
- Subject: Aw: 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>
- Sensitivity: Normal
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.
Â> 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