From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13190 invoked by alias); 2 Nov 2012 16:04:02 -0000 Received: (qmail 13062 invoked by uid 48); 2 Nov 2012 16:03:34 -0000 From: "dsmith at redhat dot com" To: systemtap@sourceware.org Subject: [Bug runtime/12642] utrace: taskfinder misses events when main thread does not go through at least one quiesce Date: Fri, 02 Nov 2012 16:04:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: runtime X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dsmith at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2012-q4/txt/msg00164.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=12642 --- Comment #3 from David Smith 2012-11-02 16:03:32 UTC --- Depending on how you count, we've got 3 or 4 sets of utrace-like functionality here, with different behaviors: 1) the original version of utrace, which is present in RHEL5, handled by runtime/linux/task_finder.c. In this case we do send the main thread a UTRACE_STOP, which causes it to stop and we attach correctly. Here your testcase passes. 2) Version 2 of utrace, which is present in RHEL6 (also handled by runtime/linux/task_finder.c). In this case we do send the main thread a UTRACE_STOP - however the stop doesn't/can't interrupt a system call. Here your testcase fails. 3) On new kernels without "real" utrace, we fake it with tracepoint handlers and task_work_add(). This code is in runtime/linux/task_finder2.c and runtime/stp_utrace.c. This code uses task_work_add() to run code when the task is stopped. This can't interrupt a system call. Here your testcase fails. 4) The new dyninst runtime ("--runtime=dyninst") uses the dyninst library to attach, which ends up using ptrace. Attaching to a running process isn't quite there yet, but I think it should be possible to interrupt a system call. So, for cases 2) and 3) above, we've still got some thinking to do. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.