Aw: Re: [RFC] Probes don't hit in an already running process

[Torsten Polle]

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