From: Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org>
To: Riku Voipio <riku.voipio@iki.fi>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] linux-user and signal handling
Date: Thu, 18 Jun 2009 21:40:24 +0200 [thread overview]
Message-ID: <873a9xs53r.fsf@lechat.rtp-net.org> (raw)
In-Reply-To: <20090618184519.GA24046@kos.to> (Riku Voipio's message of "Thu\, 18 Jun 2009 21\:45\:20 +0300")
Riku Voipio <riku.voipio@iki.fi> writes:
> 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.
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. If this can't be done, maybe this
can be clearly documented that the core bit is corrupted by qemu and
stop worrying about that. Getting a bug-free emulation is very hard
after all :)
Arnaud
next prev parent reply other threads:[~2009-06-18 19:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-18 11:56 [Qemu-devel] linux-user and signal handling Arnaud Patard
2009-06-18 13:26 ` Ulrich Hecht
2009-06-18 15:17 ` Arnaud Patard
2009-06-18 15:35 ` Ulrich Hecht
2009-06-18 16:08 ` Ulrich Hecht
2009-06-18 16:27 ` Arnaud Patard
2009-06-18 17:14 ` Daniel Jacobowitz
2009-06-18 18:45 ` Riku Voipio
2009-06-18 19:40 ` Arnaud Patard [this message]
2009-06-19 8:08 ` Riku Voipio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=873a9xs53r.fsf@lechat.rtp-net.org \
--to=arnaud.patard@rtp-net.org \
--cc=qemu-devel@nongnu.org \
--cc=riku.voipio@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).