From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N0fEj-0000aC-CK for qemu-devel@nongnu.org; Wed, 21 Oct 2009 13:44:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N0fEe-0000Rs-7J for qemu-devel@nongnu.org; Wed, 21 Oct 2009 13:44:36 -0400 Received: from [199.232.76.173] (port=53217 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N0fEd-0000Qu-Os for qemu-devel@nongnu.org; Wed, 21 Oct 2009 13:44:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49989) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N0fEd-0000jR-1t for qemu-devel@nongnu.org; Wed, 21 Oct 2009 13:44:31 -0400 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n9LHiUx1012831 for ; Wed, 21 Oct 2009 13:44:30 -0400 Message-ID: <4ADF486E.9080807@redhat.com> Date: Wed, 21 Oct 2009 19:44:14 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <20091008203740.GA20727@redhat.com> <1256063981.27918.6.camel@blaa> <4ADE0809.2050500@redhat.com> <20091021154234.GA24913@redhat.com> <4ADF44D6.5040207@redhat.com> <20091021173516.GA25112@redhat.com> In-Reply-To: <20091021173516.GA25112@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] qemu: work around for "posix-aio-compat" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Mark McLoughlin , qemu-devel@nongnu.org >> I suggest trying to make the sigset_t static, since that generates >> exactly the same code as the "nohang" case, and exactly the same stack >> layout as the "hang" case. (In case this wasn't clear: the sigfillset of a static sigset_t should hang, proving that it's stack layout that comes to the rescue). >> The next obvious step would be placing a >> watchpoint somewhere. > > Yes, but where? At every word of the sigset (using gdb commands to disable/enable the watchpoints around the sigfillset, you avoid spurious triggers). One of those words will be overwritten if an overrun would have smashed the stack. If it does not fire, s/sigfillset/sigemptyset/ in case it was writing 0xffffffff. If it still does not fire, dunno. :-( Paolo