This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]