[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 3/5] linux-user: do not avoid dumping of qemu it
From: |
Jamie Lokier |
Subject: |
Re: [Qemu-devel] [PATCH 3/5] linux-user: do not avoid dumping of qemu itself |
Date: |
Fri, 3 Jul 2009 03:25:18 +0100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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