From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L5gEB-0004v4-Dq for qemu-devel@nongnu.org; Thu, 27 Nov 2008 07:44:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L5gEA-0004uW-5O for qemu-devel@nongnu.org; Thu, 27 Nov 2008 07:44:14 -0500 Received: from [199.232.76.173] (port=55936 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L5gE8-0004uL-T8 for qemu-devel@nongnu.org; Thu, 27 Nov 2008 07:44:13 -0500 Received: from [84.20.150.76] (port=33018 helo=narury.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L5gE8-0000Vb-GB for qemu-devel@nongnu.org; Thu, 27 Nov 2008 07:44:12 -0500 Date: Thu, 27 Nov 2008 14:44:06 +0200 From: Riku Voipio Subject: Re: [Qemu-devel] [PATCH] linux-user: Proper exit code for uncaught signals Message-ID: <20081127124406.GA8274@kos.to> References: <20081123213724.GA15889@kos.to> <20081127114233.GC15592@networkno.de> <20081127121615.GC18400@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081127121615.GC18400@shareable.org> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: qemu-devel@nongnu.org On Thu, Nov 27, 2008 at 12:16:15PM +0000, Jamie Lokier wrote: > > > The proper exit code for dieing from an uncaught signal is -. > > > The kernel doesn't allow exit() or _exit() to pass a negative value. > > > To get the proper exit code we need to actually die from an uncaught > > > signal. > > It's nothing like -, so the comment should be changed. Something like: Proper exit code for dieing from an uncaught signal differs from normal exit, so applications using WISIGNALED/WTERMSIG don't get the expected result. The proper way is to actually die from an uncaught signal. > The general principle of sending yourself a signal to get the right > exit status is good. > > > + sigfillset(&act.sa_mask); > > > + act.sa_handler = SIG_DFL; > > > + sigaction(host_sig, &act, NULL); > > What if the SIG_DFL _host_ behaviour is not to terminate the host > process, but it has terminated the guest process? Awkward one. Could this happen on Linux or is this a portability issue? > > > + /* For some reason raise(host_sig) doesn't send the signal when > > > + * statically linked on x86-64. */ > > > + kill(getpid(), host_sig); > Is getpid() always right here, and should tgkill() or tkill() be used when > clone is supported? I'll have to look into this. The thought that this code needs to do multithreaded signal handling (preferredly in a portable fashion) feels like I'm heading towards endless swamplands.. -- "rm -rf" only sounds scary if you don't have backups