From owner-freebsd-bugs@FreeBSD.ORG Tue Aug 31 03:00:15 2010 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8310B10656BD for ; Tue, 31 Aug 2010 03:00:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4A6878FC1C for ; Tue, 31 Aug 2010 03:00:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o7V3093l049960 for ; Tue, 31 Aug 2010 03:00:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o7V309AV049943; Tue, 31 Aug 2010 03:00:09 GMT (envelope-from gnats) Resent-Date: Tue, 31 Aug 2010 03:00:09 GMT Resent-Message-Id: <201008310300.o7V309AV049943@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Dan McNulty Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1702C1065675 for ; Tue, 31 Aug 2010 02:58:18 +0000 (UTC) (envelope-from dkmcnulty@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id AF35C8FC0C for ; Tue, 31 Aug 2010 02:58:17 +0000 (UTC) Received: by iwn36 with SMTP id 36so6177151iwn.13 for ; Mon, 30 Aug 2010 19:58:16 -0700 (PDT) Received: by 10.231.182.196 with SMTP id cd4mr5999381ibb.191.1283222101873; Mon, 30 Aug 2010 19:35:01 -0700 (PDT) Received: from dkmcnulty@gmail.com (24-241-226-190.dhcp.mdsn.wi.charter.com [24.241.226.190]) by mx.google.com with ESMTPS id g31sm8171147ibh.4.2010.08.30.19.34.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Aug 2010 19:35:01 -0700 (PDT) Received: by dkmcnulty@gmail.com (sSMTP sendmail emulation); Mon, 30 Aug 2010 21:34:56 -0500 Message-Id: <4c7c6a55.9f3ae70a.7271.ffffe06c@mx.google.com> Date: Mon, 30 Aug 2010 21:34:56 -0500 From: "User &" To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: kern/150138: [patch] signal sent to stopped, traced process not immediately handled on continue X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dan McNulty List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 03:00:15 -0000 >Number: 150138 >Category: kern >Synopsis: [patch] signal sent to stopped, traced process not immediately handled on continue >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Aug 31 03:00:08 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Dan McNulty >Release: FreeBSD 7.2-RELEASE i386 >Organization: >Environment: FreeBSD 7.2-RELEASE FreeBSD 9.0-CURRENT (updated on 2010-08-28) >Description: In a specific case, a signal sent to a stopped, traced process is not immediately handled when the process is continued (i.e., the debugger does not know about the pending signal and the process is not stopped by the signal). Here is the scenario: A debugger is attached to a multithreaded process, where some threads are blocked in the kernel (e.g., on a mutex) 1) The debugger installs a breakpoint into the multithreaded process and continues the process 2) A single thread hits the breakpoint and the process is stopped. 3) While the process is stopped, a signal is delivered by some means to one of the threads that is blocked in the kernel 4) After dealing with the breakpoint, the debugger continues the process and doesn't learn about the new signal delivered to the blocked thread until it is no longer blocked in the kernel. >How-To-Repeat: The problem can be reproduced using the attached waitthread and tkill programs and gdb. The waitthread creates the specified number of threads and has them wait on mutex until it receives a character on a named pipe. The tkill program is used to send signals to threads using the SYS_thr_kill2 syscall. The following commands can be used to reproduce the problem (assuming waitthread and tkill have already been built). % gdb ./waitthread (gdb) set args 8 (gdb) run Starting program: /usr/home/mcnulty/scratchdev/i386-unknown-freebsd7.2/waitthread 8 [New LWP 100073] [New Thread 28404140 (LWP 100073)] 1149 [New Thread 28404280 (LWP 100054)] 100054 waiting on lock [New Thread 284043c0 (LWP 100075)] 100075 waiting on lock [New Thread 28404500 (LWP 100076)] 100076 waiting on lock [New Thread 28404640 (LWP 100082)] 100082 waiting on lock [New Thread 28404780 (LWP 100086)] 100086 waiting on lock [New Thread 284048c0 (LWP 100087)] 100087 waiting on lock [New Thread 28404a00 (LWP 100088)] 100088 waiting on lock [New Thread 28404b40 (LWP 100089)] 100089 waiting on lock # at another prompt, send signals to different threads % procstat -t 1149 PID TID COMM TDNAME CPU PRI STATE WCHAN 1149 100054 waitthread - 0 160 sleep umtxn 1149 100073 waitthread initial thread 0 160 sleep fifoor 1149 100075 waitthread - 0 160 sleep umtxn 1149 100076 waitthread - 0 160 sleep umtxn 1149 100082 waitthread - 0 160 sleep umtxn 1149 100086 waitthread - 0 160 sleep umtxn 1149 100087 waitthread - 0 160 sleep umtxn 1149 100088 waitthread - 0 160 sleep umtxn 1149 100089 waitthread - 0 160 sleep umtxn # simulate the breakpoint % ./tkill 1149 100054 5 # simulate the new signal, sent to a blocked thread % ./tkill 1149 100086 2 # gdb should know about the trap signal Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 28404280 (LWP 100054)] 0x2809f475 in __error () from /lib/libthr.so.3 (gdb) c Continuing. # after continuing the process, the process never stops because of the pending SIGINT >Fix: The attached patch ( to CURRENT ) takes a stab at fixing the problem. The patch adds code so that even if the process is being traced, a signal sent to a interruptibly sleeping thread wakes up the thread so it will handle the signal when the process leaves the stopped state. The added code was copied from the code that handled stopped, non-traced processes later in the same function. >Release-Note: >Audit-Trail: >Unformatted: