From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2655 invoked by alias); 9 Jun 2010 14:39:55 -0000 Received: (qmail 1987 invoked by uid 48); 9 Jun 2010 14:39:20 -0000 Date: Wed, 09 Jun 2010 22:26:00 -0000 Message-ID: <20100609143920.1986.qmail@sourceware.org> From: "mjw at redhat dot com" To: systemtap@sources.redhat.com In-Reply-To: <20100607130056.11672.mjw@redhat.com> References: <20100607130056.11672.mjw@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug uprobes/11672] utrace_report_syscall_exit crash X-Bugzilla-Reason: AssignedTo 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: 2010-q2/txt/msg00511.txt.bz2 ------- Additional Comments From mjw at redhat dot com 2010-06-09 14:39 ------- After reading the code I think we weren't handling utrace_control UTRACE_DETACH returning -EINPROGRESS totally correctly. Which could theoretically lead to unloading the module before the handlers were totally done (which could theoretically lead to this crash). I tried to make the handling explicit in this commit: commit 9cb8092cf84d18e7435f03eef3963e01ea4e993f Author: Mark Wielaard Date: Wed Jun 9 11:50:48 2010 +0200 Loop on utrace_barrier if utrace_control UTRACE_DETACH returns -EINPROGRESS. When utrace_control(tsk, eng, UTRACE_DETACH) returns -EINPROGRESS that means there are still handlers running. So loop on utrace_barrier(tsk, eng) in that case, till it no longer returns -ERESTARTSYS. That makes sure that no engine handler will be called afterwards, so we can safely unload the stap module. Not doing this might have caused PR11672 (utrace_report_syscall_exit crash), although we don't yet have a simple reproducer for that issue. * runtime/itrace.c (remove_usr_itrace_info): Loop on utrace_barrier if utrace_control returned -EINPROGRESS. * runtime/task_finder.c (stap_utrace_detach): Likewise. (stap_utrace_detach_ops): Likewise. And warn if stap_utrace_detach didn't return successfully. (__stp_utrace_attach): Loop on -ERESTARTSYS after utrace_barrier. (__stp_utrace_task_finder_target_quiesce): Likewise. I added a bit more error reporting in a followup commit, to catch anything going wrong during detach: commit 722a48dbe4ea51e798a137cb40663812126b2939 Author: Mark Wielaard Date: Wed Jun 9 12:48:14 2010 +0200 Add more error messages when something goes wrong during task_finder detach. * runtime/task_finder.c (stap_utrace_detach): Report when utrace_barrier fails. (stap_utrace_detach_ops): Report how stap_utrace_detach failed. On irc roland said that newer utrace have a new enginer callback "release" that is called when the engine (and its handlers) are totally done. We could use that instead of trying to track things ourselves before unloading the module. But it isn't available in older utrace implementations. So far I haven't been able to reproduce the crash (with or without the above patches). Still monitoring. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11672 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.