From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MHMcB-0004Ig-Dp
	for qemu-devel@nongnu.org; Thu, 18 Jun 2009 14:45:35 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MHMc8-0004HL-Vf
	for qemu-devel@nongnu.org; Thu, 18 Jun 2009 14:45:34 -0400
Received: from [199.232.76.173] (port=57331 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MHMc8-0004HG-Ni
	for qemu-devel@nongnu.org; Thu, 18 Jun 2009 14:45:32 -0400
Received: from naru.obs2.net ([84.20.150.76]:38571)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <nchip@kos.to>) id 1MHMc8-0003zn-5S
	for qemu-devel@nongnu.org; Thu, 18 Jun 2009 14:45:32 -0400
Date: Thu, 18 Jun 2009 21:45:20 +0300
From: Riku Voipio <riku.voipio@iki.fi>
Subject: Re: [Qemu-devel] linux-user and signal handling
Message-ID: <20090618184519.GA24046@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090618171439.GA32373@caradoc.them.org>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Daniel Jacobowitz <drow@false.org>
Cc: qemu-devel@nongnu.org, Arnaud Patard <arnaud.patard@rtp-net.org>

On Thu, Jun 18, 2009 at 01:14:39PM -0400, Daniel Jacobowitz wrote:
> On Thu, Jun 18, 2009 at 06:27:02PM +0200, Arnaud Patard wrote:
> > Ulrich Hecht <uli@suse.de> writes:
> > 
> > > On Thursday 18 June 2009, Ulrich Hecht wrote:
> > >> And the culprit indeed
> > >> seems to be edf8e2af1453ce56c72b2f25a745e3734177a05d
> > >
> > > Specifically, it's the part in force_sig() that sets the core limit to 0 
> > > to prevent a core dump of qemu itself that causes the wrong core bit. 
> > > Remove it, and the test passes. No idea how to fix that properly, 
> > > though.
> > 
> > ok. That's interesting... Will look at that. Thanks a lot !
> 
> Sounds to me like what's happening is a feature... trading off a
> host core dump for a target core dump.

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.