From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MMYSs-0004Rc-5C for qemu-devel@nongnu.org; Thu, 02 Jul 2009 22:25:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MMYSn-0004R5-JU for qemu-devel@nongnu.org; Thu, 02 Jul 2009 22:25:25 -0400 Received: from [199.232.76.173] (port=60681 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMYSn-0004R2-G2 for qemu-devel@nongnu.org; Thu, 02 Jul 2009 22:25:21 -0400 Received: from mail2.shareable.org ([80.68.89.115]:48758) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MMYSm-0006Ne-Vu for qemu-devel@nongnu.org; Thu, 02 Jul 2009 22:25:21 -0400 Date: Fri, 3 Jul 2009 03:25:18 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 3/5] linux-user: do not avoid dumping of qemu itself Message-ID: <20090703022518.GC938@shareable.org> References: <200907020032.00212.paul@codesourcery.com> <20090702021921.GB18372@shareable.org> <200907021419.30327.paul@codesourcery.com> <20090702200102.GA7219@kos.to> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090702200102.GA7219@kos.to> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Riku Voipio Cc: Paul Brook , Arnaud Patard , qemu-devel@nongnu.org Riku Voipio wrote: > On Thu, Jul 02, 2009 at 02:19:29PM +0100, Paul Brook wrote: > > > > [1] A host core dump may be useful for debugging qemu itself, but that's > > > > a fairly specialized corner case, and not necessarily something we want > > > > to be exposing to users. > > > > It would make sense to set RLIMIT_CORE to zero very early in > > > qemu-user, and then someone debugging qemu-user can easily change > > > RLIMIT_CORE from gdb while it is running. > > > Sounds reasonable, as long as you're careful to avoid breaking guest > > applications that call {get,set}rlimit(RLIMIT_CORE). > > The host process coredump is still not very useful, as kernel creates it > only after we come out of our signal handler? The kernel will create the host coredump when the host process dies. That is, when it receives a fatal unhandled signal. Generally I'd expect we shouldn't create a coredump if QEMU sends itself a signal deliberately, just to indicate that the process terminates with a guest signal. But it would be a bit more useful when QEMU receives a signal due to a bug in QEMU (when debugging sets RLIMIT_CORE). There might not be a clean way to distinguish the two conditions. > Also, I don't think there > is any real world application that would behave unexpectedly if one > of it's child processes dies without the coredump bit being set... I agree, I've never heard of any. Quite a few will behave differently, in a minor way, such as the different termination message shown by shells. -- Jamie