From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MHZ99-0005WF-Bn for qemu-devel@nongnu.org; Fri, 19 Jun 2009 04:08:27 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MHZ98-0005Ve-Rd for qemu-devel@nongnu.org; Fri, 19 Jun 2009 04:08:26 -0400 Received: from [199.232.76.173] (port=39775 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MHZ98-0005VO-Iu for qemu-devel@nongnu.org; Fri, 19 Jun 2009 04:08:26 -0400 Received: from naru.obs2.net ([84.20.150.76]:45909) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MHZ97-0006oW-Jr for qemu-devel@nongnu.org; Fri, 19 Jun 2009 04:08:26 -0400 Date: Fri, 19 Jun 2009 11:08:23 +0300 From: Riku Voipio Subject: Re: [Qemu-devel] linux-user and signal handling Message-ID: <20090619080823.GB20694@kos.to> References: <87fxdxsqks.fsf@lechat.rtp-net.org> <87bpolsh9o.fsf@lechat.rtp-net.org> <200906181735.09280.uli@suse.de> <200906181808.15408.uli@suse.de> <877hz9se21.fsf@lechat.rtp-net.org> <20090618171439.GA32373@caradoc.them.org> <20090618184519.GA24046@kos.to> <873a9xs53r.fsf@lechat.rtp-net.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <873a9xs53r.fsf@lechat.rtp-net.org> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Arnaud Patard Cc: qemu-devel@nongnu.org On Thu, Jun 18, 2009 at 09:40:24PM +0200, Arnaud Patard wrote: > Riku Voipio writes: > > Or to be more specific, trading off a unneeded core dump of a qemu process > > (since we got a core dump of the target process) to not having core bit set > > in exit status. > > If people depend on WCOREDUMP(), we can remove that bit of eliminating > > the host process coredump. > I understand the idea is to get coredump for the target and not of the > host. What's worrying me is that it should be transparent to the target > and it's not the case. > It would be nice if this can be fixed. It can be fixed - like with the patch below. The question is which people want it? I'm beginning to think we should go with the correctness and live with the slighly annoying extra coredump. >>From ee2f075ebbfa35f11bcfffb813ed6288e536262b Mon Sep 17 00:00:00 2001 Message-Id: From: Riku Voipio Date: Fri, 19 Jun 2009 10:49:57 +0300 Subject: [PATCH 5/5] linux-user: do not avoid dumping of qemu itself Previously we disabled dumping of qemu itself if we already created coredump of the target process. This broke the abort01 LTP test and any application that used WCOREDUMP to find out the child process dumped core. Remove this feature. Signed-off-by: Riku Voipio --- linux-user/signal.c | 6 ------ 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/linux-user/signal.c b/linux-user/signal.c index 6a34171..e1b6458 100644 --- a/linux-user/signal.c +++ b/linux-user/signal.c @@ -383,12 +383,6 @@ static void QEMU_NORETURN force_sig(int sig) ((*ts->bprm->core_dump)(sig, thread_env) == 0); } if (core_dumped) { - /* we already dumped the core of target process, we don't want - * a coredump of qemu itself */ - struct rlimit nodump; - getrlimit(RLIMIT_CORE, &nodump); - nodump.rlim_cur=0; - setrlimit(RLIMIT_CORE, &nodump); (void) fprintf(stderr, "qemu: uncaught target signal %d (%s) - %s\n", sig, strsignal(host_sig), "core dumped" ); } -- 1.6.2.1