From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 20:41:35 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9B351065673 for ; Wed, 24 Aug 2011 20:41:35 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 433118FC15 for ; Wed, 24 Aug 2011 20:41:34 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QwKGf-000Jr2-Uk; Thu, 25 Aug 2011 00:41:45 +0400 Date: Thu, 25 Aug 2011 00:41:45 +0400 From: Slawa Olhovchenkov To: Kostik Belousov Message-ID: <20110824204145.GA75535@zxy.spb.ru> References: <20110824181907.GA48394@zxy.spb.ru> <20110824190703.GY17489@deviant.kiev.zoral.com.ua> <20110824192446.GB48394@zxy.spb.ru> <20110824193202.GZ17489@deviant.kiev.zoral.com.ua> <20110824194229.GC48394@zxy.spb.ru> <20110824195035.GA17489@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110824195035.GA17489@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org Subject: Re: sigwait return 4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 20:41:35 -0000 On Wed, Aug 24, 2011 at 10:50:35PM +0300, Kostik Belousov wrote: > On Wed, Aug 24, 2011 at 11:42:29PM +0400, Slawa Olhovchenkov wrote: > > On Wed, Aug 24, 2011 at 10:32:02PM +0300, Kostik Belousov wrote: > > > > > > > What should the system do for a delivered signal not present in the set ? > > > > > I guess this is the case of your ktrace. > > > > > > > > > > Looking at the SUSv4, I see no mention of the situation, but in Oracle > > > > > SunOS 5.10 man page for sigwait(2), it is said explicitely > > > > > EINTR The wait was interrupted by an unblocked, caught signal. > > > > > > > > I don't think you right in this case. > > > > This is kas-milter and in this thread (this is multi-thread > > > > application) kas-milter wait for USR2 for reload config. > > > > > > > > System return from sigwait only on USR2, but not each return w/ > > > > non-zero return code. > > > > > > > > On freebsd7 this application don't complain about sigwait's return value. > > > > > > Could it be that some other thread has the signal unblocked ? > > > (You can verify this with procstat -j). > > > > > > Can you write the self-contained test case that demonstrates the behaviour ? > > > > This is closed-source software. > How is this statement related to the creation of the standalone test case ? > > > # procstat -j > > PID TID COMM SIG FLAGS > > 1395 100199 kas-milter USR2 -- > > 1395 100232 kas-milter USR2 -- > > Both threads have the signal not blocked. This is not definitive, > since signal must be blocked during the call to sigwait(2). Note that > the SUSv4 says that "The signals defined by set shall have been > blocked at the time of the call to sigwait(); otherwise, the behavior is > undefined." I see some strange in debug: # kdump -H -f /ktrace.out | grep sigw 1396 100228 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) # ktrdump | grep sigw 738 syscall: td=0xffffff002549d900 pid 1396 sigwait (0xffdfdf80, 0xffdfdf7c, 0xffffff8117827bf0) 666 syscall: td=0xffffff000c3d9900 pid 1286 sigwait (0x7fffffbfef70, 0x7fffffbfef8c, 0) 660 syscall: td=0xffffff00251ed900 pid 1277 sigwait (0x7ffffddeff70, 0x7ffffddeff8c, 0) 51 syscall: td=0xffffff0004ac5000 pid 787 sigwait (0x7fffffffebb0, 0x7fffffffebdc, 0) now I see 3'th non-zero argument from pid 1396.