qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] linux-user and signal handling


From: Rtp
Subject: Re: [Qemu-devel] linux-user and signal handling
Date: Thu, 18 Jun 2009 21:40:24 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Riku Voipio <address@hidden> 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 <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]