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: David Smith <dsmith at redhat dot com>
- To: Torsten Polle <Torsten dot Polle at gmx dot de>, systemtap at sourceware dot org
- Date: Thu, 13 Mar 2014 08:46:15 -0500
- 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>
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>
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)