Re: [Qemu-devel] [PATCH 3/5] linux-user: do not avoid dumping of qemu itself

[Jamie Lokier <jamie@shareable.org>]

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